[00:48:34] <-- armav has left IRC ()
[00:55:41] <Darke> From a newsgroup post: "Actually Crusader uses less than 10% of the code from U8..." It'd be interesting to try and verify/dispite this claim. I'm pretty sure the usecode interpreter is almost identical, so that's about 10% in itself, if not more. *grin*
[01:19:47] <Darke> Hmm... there's a PSX version of Crusader: No Remorse?
[01:44:02] --> Kirben has joined #exult
[01:44:03] --- ChanServ gives channel operator status to Kirben
[05:04:48] <-- Darke has left IRC (Remote closed the connection)
[05:06:13] --> Darke has joined #exult
[05:06:13] --- ChanServ gives channel operator status to Darke
[06:04:54] --> EsBee-Eks has joined #exult
[06:04:57] <EsBee-Eks> Hi.
[06:06:11] * Darke bows. Hi.
[06:09:41] * EsBee-Eks is going to start calling himself part of your fanbase.
[06:12:54] * Darke turns EsBee-Eks's dial to 'hi' and sits in front of him, in the path of his cooling breeze.
[06:20:29] * EsBee-Eks tells Darke not to quit his day job. ;-)
[06:21:03] * Darke doesn't. *grin*
[06:29:20] * EsBee-Eks wonders if there are 'lo' and 'mid' settings.
[06:30:09] * Darke doesn't ask about the buttons that turn EsBee-Eks on and off. *innocentwhisle*
[06:31:34] * EsBee-Eks doesn't ask about TonysBalls.
[06:46:11] * Darke thinks TonysBalls are cool. It looks like a really funky function. *grin*
[07:30:48] * EsBee-Eks just realized void parameters are the standard way to prototype functions without any arguments.
[07:31:56] <Darke> Eh? Like `foo(void);` rather then `foo();`?
[07:32:15] * EsBee-Eks thought it was just a style some people used. :P
[07:32:15] <EsBee-Eks> yeah
[07:32:27] <EsBee-Eks> extern assembled rmo *rmo_new(void);
[07:32:38] <EsBee-Eks> extern assembled_rmo *rmo_new(void);
[07:33:03] <Darke> It is. AFAICT, both are valid, but I see the latter much, much more often then the former, since the 'void', doesn't really add any extra information, but requires more typing.
[07:33:52] <EsBee-Eks> that is why I've never used it :)
[07:34:20] * EsBee-Eks just realized he wasn't using that rmo_new function anyway.
[07:36:00] * Darke would, if he wrote the specs, require that the void keyword _never_ be used, unless it was part of a pointer or reference. Writing foo(void) makes as much sense to him as writing foo(theres_nothing_here); It's either blatently obvious or actually 'incorrect' logically, since there is something there 'theres_something_here'. *grin*
[07:37:21] <EsBee-Eks> overzealous prototyping
[07:37:21] <EsBee-Eks> heh
[07:37:31] <EsBee-Eks> would foo(void); and foo(); conflict?
[07:38:02] <Darke> I've never seen them conflict in the compilers I've tried it in. They're identical.
[07:38:18] <EsBee-Eks> Does foo(void, void); make sense?
[07:38:18] * Darke suggests actually trying it in gcc, just to see. *grin*
[07:38:24] <Darke> Nope.
[07:38:33] <EsBee-Eks> or even less sense than 1 void? :)
[07:38:59] <EsBee-Eks> void main(void, void)
[07:39:08] <Darke> foo(void *, void *) makes sense, because a void * can exist, from what I've read, a void can never exist.
[07:40:56] <EsBee-Eks> () and (void) don't conflict
[07:41:33] <EsBee-Eks> neither to (void nothinghere) and ()
[07:41:49] <EsBee-Eks> s/to/do/
[07:42:40] <Darke> Curious. I never knew you could 'name' a void type. *grin* Did you try the foo(void, void)?
[07:43:54] <EsBee-Eks> theprog.c:1: `void' in parameter list must be the entire list
[07:44:15] <EsBee-Eks> theprog.c: In function `foo':
[07:44:15] <EsBee-Eks> theprog.c:1: parameter name omitted
[07:47:29] <Darke> AKA. We'll happily ignore you actually trying to give a name to a void typed object, just like we ignore the void typed object itself because it's completely redundant, and becuase they don't exist. But trying to pass two objects that don't exist to a function, is Just Not On.
[07:50:58] <EsBee-Eks> I still think it is less confusing than C++. :)
[07:51:46] <EsBee-Eks> On the same path of logic, should you not need the 'void' return type for functions with no return?
[07:52:26] <Darke> Of course C++ is just C in a Mech, that's all. Much larger, much more cumbersome, but can be used to much easily flatten large amounts of landscape.
[07:52:54] <Darke> Yeah. Except by default in pre-ansi-C the default 'no return type' was int. So you're stuck using a 'void' return.
[07:56:38] <EsBee-Eks> I can't find the part in the standard now about void parameters, but does know that (void) is used in the examples instead of ().
[07:56:58] <EsBee-Eks> oops
[07:57:06] <EsBee-Eks> s/does/I do/
[07:57:38] * Darke snickers, or perhaps s/I/\/me/ ? *grin*
[07:58:18] <EsBee-Eks> why for u make fun?
[07:59:30] * Darke laughs evily, and is slowly corrupting others to pose like this. *fangygrin*
[08:01:10] <EsBee-Eks> Here is what it says about void: 220.127.116.11 void The (nonexistant) value of a void expression (an expression that has type void) shall not be used in any way, and implicit or explicit conversions (except to void) shall not be applied to such an expression. If an expression of any other type is evaluated as a void expression, its value or designator is discarded. (A void expression is evaluated for its side effects.)
[08:02:21] <EsBee-Eks> The void type comprises an empty set of values; it is an incomplete type that cannot be completed.
[08:04:32] <Darke> So you can't actually do anything wich it, since you can't actually effect it, although the code you write may effect it as a side affect of it's operation.
[08:05:00] <Darke> Of course, this doesn't matter anyway, since you can't actually 'access' this value to use it in any way, shape or form anyway.
[08:05:20] * Darke thinks that's what it says.
[08:07:32] * EsBee-Eks typed it because xpdf does not have a copy text feature.
[08:08:22] * Darke noticed that 'problem' with xpdf. *ick*
[08:09:09] * EsBee-Eks downloaded this from the web and isn't sure if it is legal, but it is probably just a draft.
[08:10:33] <EsBee-Eks> ISO/IEC 9899:1999
[08:10:52] <Darke> Hmm... that looks up to date.
[08:11:27] <EsBee-Eks> Did you know there is supposed to be a Boolean type?
[08:11:44] <EsBee-Eks> bool, true, false like in C++, implemented with macros
[08:12:02] <EsBee-Eks> stdbool.h
[08:12:23] <Darke> *nod* gcc even implements it, and has implemented it for... ages.
[08:12:47] * EsBee-Eks can't find it.
[08:13:17] <EsBee-Eks> oh it isn't in /usr/include
[08:14:10] * Darke thinks it was implemented 'internally' rather then in stdboo.h. But he was sure he used bool in a C program, then was surprised it worked.
[08:15:25] <EsBee-Eks> -rw-r--r-- 1 root root 502 Mar 18 2001 /usr/lib/gcc-lib/i386-slackware-linux/2.95.3/include/stdbool.h
[08:15:58] <Darke> Or apparently not. *grin*
[08:16:38] <EsBee-Eks> #define true true
[08:16:38] <EsBee-Eks> heh
[08:16:48] <EsBee-Eks> it is enumerated above that
[08:17:28] * Darke thinks the small section of #defines in this header is just bizzare. *grin*
[08:17:40] <EsBee-Eks> anyway... document says: 1 The header <stdbool.h> defines four macros.
[08:17:53] <EsBee-Eks> 2 The Macro bool expands to _Bool.
[08:19:08] <EsBee-Eks> 3 The remaining three macros are suitable for use in #if proprocessing directives. They are true which expands to the integer constant 1 and false which expands to the integer constant 0, and __bool_true_false_are_defined which expands to the integer constant 1.
[08:19:50] <EsBee-Eks> and 4 Notwithstanding the provisions of 7.1.3, a program may undefine and perhaps then redefine the macros bool, true, and false. (213)
[08:20:22] * Darke aiees and cowers in horror at point 4.
[08:20:24] <EsBee-Eks> 213) "future library directions" (7.26.7)
[08:20:41] <EsBee-Eks> 213) See "future library directions" (7.26.7).
[08:20:41] <EsBee-Eks> :P
[08:20:59] <EsBee-Eks> what size is your header?
[08:20:59] <EsBee-Eks> heh
[08:21:11] * Darke can quite easily see people defining true to be 0 and false to be 1.
[08:21:17] <EsBee-Eks> #define stdout bool
[08:21:17] <EsBee-Eks> #define bool !false
[08:21:17] <EsBee-Eks> #define false Darkes_worst_nightmare
[08:21:49] <Darke> Take your pick. My 2.95.3 one is 502bytes, the 3.0.4 one, 1612bytes.
[08:22:16] <EsBee-Eks> can i see the big one?
[08:22:32] <EsBee-Eks> well i could probably download it
[08:22:37] <EsBee-Eks> from somewhere else
[08:23:00] <EsBee-Eks> thanks
[08:23:02] * EsBee-Eks looks.
[08:24:32] <EsBee-Eks> this actually sticks to the what i read more than the small file
[08:25:07] * Darke nods.
[08:25:57] <Darke> 2.95.x isn't maintaned anymore, and I don't think it has been for a while. I expect that smaller file was originally created some time ago, and not updated because it might 'break' programs currently in existance.
[08:27:07] <EsBee-Eks> You think I can add this one to /usr/include without breaking anything?
[08:27:34] <EsBee-Eks> if that is where it goes
[08:29:35] <Darke> You'll likely need to replace it with the one you located above.
[08:29:53] <Darke> The file originally came from: /usr/lib/gcc-lib/i686-pc-linux-gnu/3.0.4/include/stdbool.h
[08:30:49] <EsBee-Eks> I hope it finds it.
[08:31:04] <EsBee-Eks> Are you still using Gentoo and optimized everything?
[08:31:33] <Darke> Yup. That's why it's in the i686 directory on my machine, you'll need to drop it into the i386-slackware directory on yours.
[08:32:21] * EsBee-Eks wants an i686 directory. :(
[08:32:25] * Darke actually figures you're better off grabbing gcc3.0.4 or 3.1 off gnu's website and compiling it yourself overnight. It's _really_ painfree if it works you know. *grin*
[08:32:49] <Darke> i586 most likely will be your directory, IIRC you said you were on a pentium. *grin*
[08:32:58] <EsBee-Eks> ... if it works ...
[08:33:28] * EsBee-Eks only has an i586, but still wants an i686 directory. :(
[08:33:48] * EsBee-Eks wants an i686 in fact.
[08:34:12] <EsBee-Eks> None of Slackware's programs are built for even 586.
[08:34:24] * EsBee-Eks ponders recompiling the entire distro.
[08:35:47] <Darke> So? Just recompile the bits you actually use. Exult will actually run faster on your machine then, sdl as well, and you probably want to recomple X and your window manager too. *grin*
[08:36:37] <EsBee-Eks> will still take a while
[08:36:43] <EsBee-Eks> How much faster do you think it will be?
[08:36:47] <Darke> If it doesn't work, then you've 'wasted' 8 hours of your machine compiling gcc for nothing. *grin*
[08:37:08] <EsBee-Eks> oh, nothing big then
[08:37:10] <EsBee-Eks> heh
[08:37:12] <EsBee-Eks> :P
[08:37:17] <Darke> It's very variable. I noticed a big increase in the resposiveness of things.
[08:43:08] * Darke would suggest trying to comple gcc. If if does install, and decides not comple some of your programs properly (I've not had a problem), then you can just run rpm and reinstall your distro's gcc.
[08:44:09] * EsBee-Eks is not using rpm.
[08:44:20] <EsBee-Eks> You say the newest GCC compiles programs to run faster?
[08:46:53] <Darke> *nod* There's a paper around somewhere that describes how it optimises. Just a sec and I'll see if I can find it.
[08:47:36] <EsBee-Eks> this might make you stop sweating...
[08:48:04] <EsBee-Eks> 7.26.7 Boolean types and values <stdbool.h>
[08:48:38] <EsBee-Eks> 1 The ability to undefine and perhaps then redefine the macros bool, true, and false is an obsolescent feature.
[08:48:51] * Darke yays!
[08:50:05] <EsBee-Eks> 99.Q Voidedness - The non-existant type 'void' shall never be used.
[08:50:05] * EsBee-Eks can't find that one.
[09:13:31] --> wjp has joined #exult
[09:13:31] --- ChanServ gives channel operator status to wjp
[09:13:31] <wjp> hi
[09:13:32] * Darke bows. Hi.
[09:18:05] <-- Kirben has left IRC (calvino.openprojects.net irc.openprojects.net)
[09:18:05] <-- kefka_ has left IRC (calvino.openprojects.net irc.openprojects.net)
[09:18:05] <-- Darke has left IRC (calvino.openprojects.net irc.openprojects.net)
[09:18:05] <-- wjp has left IRC (calvino.openprojects.net irc.openprojects.net)
[09:18:05] <-- EsBee-Eks has left IRC (calvino.openprojects.net irc.openprojects.net)
[09:18:50] --> wjp has joined #exult
[09:18:50] --> EsBee-Eks has joined #exult
[09:18:50] --> Darke has joined #exult
[09:18:50] --> Kirben has joined #exult
[09:18:50] --> kefka_ has joined #exult
[09:19:17] * Darke nods. Looks like it.
[09:19:44] <wjp> if I read that stderr correctly it means the problem is in listfiles
[09:20:01] <wjp> ...which is kind of strange
[09:20:05] <EsBee-Eks> ???
[09:20:53] <wjp> it's apparently happening in both a mingw- and a msvc-compiled version, so it probably isn't a library problem
[09:21:10] <wjp> I wonder what changes in exult triggered this
[09:21:40] <EsBee-Eks> what is being talked about?
[09:22:03] <wjp> some strange bug in windows that causes only one savegame to show up in the savegame screen
[09:23:02] <EsBee-Eks> oh yeah
[09:23:36] <EsBee-Eks> -2 is quicksave?
[09:23:47] <wjp> empty slot
[09:24:03] * Darke touched the filehandling stuff within the last few weeks, but that doesn't explain it happening for "nealy all of the Windows snapshots since RC1". And it also doesn't explain why it's happening on windows only, since his changes should effect both.
[09:24:32] <wjp> Darke: problem is in the U7ListFiles function. You only touched things like U7Open, right?
[09:25:25] <Darke> I should have. But it might also have effected functions that open a file to test if it exists.
[09:25:40] <wjp> U7ListFiles doesn't use that
[09:25:47] <wjp> it just uses FindFirst/FindNext
[09:25:50] <Darke> I know I tiptoed around one such function and double checked it was actually throwing the correct exception.
[09:26:06] <Darke> *nod* In which case, none of my changes should have effected it.
[09:28:37] <wjp> hm, it seems GetShortPathName is called on the search pattern
[09:30:19] <wjp> I wonder if GetShortPathName accidentally expands the * in some weird cases
[09:31:41] <Darke> Bizzare thought. What OS are they running on? I know with NT based ones you can turn off short pathname emulation under NTFS. But it looks like they're all using win98.
[09:33:29] <wjp> yeah, looks like it
[09:34:19] <wjp> hm, GetShortPathName apparently fails when the file doesn't exist
[09:34:35] * wjp is reading the Wine implementation of it, btw
[09:35:15] <EsBee-Eks> How do you know that is the same as the original?
[09:35:31] <wjp> you don't :-)
[09:35:58] <wjp> but it might give some extra insight compared with the MSDN docs
[09:36:19] <wjp> (which hardly mention any special cases)
[09:36:47] * Darke notes the MSDN docs do have that annoying flaw...
[09:37:26] * EsBee-Eks read a post on a comp.* group that said the MSDN docs should burn in hell.
[09:37:32] <wjp> it's common for all MS products.. software and docs :-)
[09:39:43] <wjp> hm... it looks like the Wine version _might_ expand wildcards
[09:41:43] <wjp> I'll reboot to win98 and check it thereb
[09:41:43] <wjp> s/reb/re/
[09:41:43] <wjp> brb
[09:41:46] <-- wjp has left IRC ("brb")
[09:42:07] * Darke 's first encounter with VisualC++ was in a programming subject where, despite the fact they'd installed all of the MSDN including the stuff detailing the std c++lib and clib, the documentation on it was useless. It was also his last encounter with VisualC++.
[09:42:32] * EsBee-Eks only has Win95.
[09:43:12] <EsBee-Eks> Is Mingw better than VC++? (and documented better)
[09:43:47] --> wjp has joined #exult
[09:43:47] --- ChanServ gives channel operator status to wjp
[09:44:38] <wjp> what was that function again? GetShortPathName?
[09:44:42] <Darke> EsBee-Eks: Not that I know of. But at least the lecturer isn't telling you to refer to it's docs for more information.
[09:44:45] * wjp doesn't have exult sources here
[09:44:54] <Darke> Yep.
[09:45:07] <Darke> <wjp> hm, it seems GetShortPathName is called on the search pattern
[09:46:14] <EsBee-Eks> Is that a function that didn't exist in Win95?
[09:46:29] <wjp> according to MSDN it existed in W95
[09:47:38] <EsBee-Eks> One time you were talking about a function that didn't, and it caused some problems when Colourless used it.
[09:47:54] <EsBee-Eks> Maybe it was NT.
[09:47:54] <EsBee-Eks> but I think the function had to do with pathnames
[09:47:54] * EsBee-Eks shrugs.
[09:51:27] <wjp> wow, this hangs MSVC when I run it
[09:51:38] <wjp> (the program does run properly, but MSVC just segfaults)
[09:52:11] <wjp> ok, that was indeed the problem
[09:53:20] <wjp> GetShortPathName expands wildcards... how nice
[09:53:30] <wjp> brb again
[09:53:30] <-- wjp has left IRC ("Leaving")
[09:54:40] <EsBee-Eks> :)
[09:56:02] --> wjp has joined #exult
[09:56:02] --- ChanServ gives channel operator status to wjp
[09:59:33] * Darke hops off to persue some fluffy Z's. Night all, see you on the flip side. *grin*
[09:59:37] --- Darke is now known as Darke|afk
[10:00:07] <wjp> night
[10:05:48] <EsBee-Eks> wjp
[10:06:30] <EsBee-Eks> are loops supposed to take 99% of CPU time?
[10:06:52] <wjp> depends on the loop
[10:07:16] <wjp> tight loops with no I/O or sleeps in it should take up all available CPU, yes
[10:07:45] <EsBee-Eks> i have lots of programs running only taking 6% of cpu, and I assume they use control loops, but mine take it all
[10:07:57] <EsBee-Eks> oh, I/O and sleeps
[10:08:19] <EsBee-Eks> i should use select()?
[10:08:30] <wjp> dunno
[10:08:39] <wjp> I'm not that familiar with these things
[10:08:52] <wjp> Exult uses SDL_Sleep
[10:11:18] <EsBee-Eks> ok thanks, I think I could make a timer that sends a signal to the process and listen for that and other input simultaneously
[10:22:18] * EsBee-Eks goes to waste his bandwidth downloading big files.
[10:22:21] <-- EsBee-Eks has left IRC ("X-Chat [1.6.4]")
[10:50:47] --> Fingolfin has joined #exult
[11:02:25] <wjp> hi
[11:07:26] <Fingolfin> yo
[12:36:40] --> Nadir has joined #exult
[12:36:41] --- ChanServ gives channel operator status to Nadir
[12:36:50] <wjp> hi
[12:36:54] <Nadir> hi
[12:46:57] --> Colourless has joined #Exult
[12:46:57] --- ChanServ gives channel operator status to Colourless
[12:47:10] <Colourless> hi
[12:47:11] <wjp> hi
[12:47:32] * wjp points at logs from 2-3 hours ago
[12:47:56] * Colourless interpretes this as some sort of hint
[12:48:21] * wjp is glad Colourless got the hint :-)
[12:49:44] <wjp> brb, going to get some lunch
[12:49:49] <Colourless> about saves?
[12:51:15] <Colourless> it probably is myfault i think
[12:51:53] <Colourless> GetShortPathName is probably where the problem is occuring.
[12:52:01] <Colourless> I'll make a work around
[12:52:15] <Colourless> and then i'll get someone to try
[12:52:37] <wjp> b
[12:52:47] <wjp> yeah, GetShortPathName expands wildcards
[12:53:09] <wjp> (in my Win98 it does, anyway)
[12:55:02] <Colourless> if SBX was still here i would have to tell him that for general game engines, loops do take up 99% of CPU time
[12:55:50] <wjp> he should be back.. he just left to save some bandwidth, IIRC
[12:56:05] <wjp> (not that IRC takes up any noticeable bandwidth)
[12:56:06] <Colourless> you never call Sleep() type funcs because the delay can actually be far too long
[12:56:17] <wjp> we call sleep :-)
[12:56:36] <Colourless> yeah I know we do :-)
[12:56:43] <Colourless> if you want as fast a frame limit as possible, sleep can limit you to less than 30 fps
[12:57:57] <Colourless> games != well behaving applications
[12:58:15] <wjp> yeah.. but that's allowed since games generally don't run in the background :-)
[12:58:36] <Colourless> exactly :-)
[13:00:00] <Colourless> doesn't really matter for exult our frame limit is loosely capped to 20 fps. Might matter a bit more with pentagram though
[13:07:22] <Nadir> Darke|afk: are you btk ?
[13:09:02] <Colourless> i think i'll commit these changes. no need to wait
[13:25:20] <wjp> hm, I'm not sure if doing GetShortPathName only in specific circumstances in a good idea
[13:25:29] <wjp> it might cause some unpredictable behaviour
[13:25:41] <wjp> s/in/is/
[13:25:47] <Colourless> such as?
[13:26:00] <Colourless> i decided to only use it if there is a space in the name
[13:26:27] <Colourless> it really shouldn't matter. the function shouldn't even be required in the first place
[13:26:52] <wjp> yeah, it didn't fix the spaces issue, did it?
[13:27:25] <Colourless> i have no idea what the space issue even is
[13:28:19] <Colourless> and i don't really know if it did, or didn't work
[13:29:41] <Colourless> things suggest it didn't.
[13:40:49] <Kirben> Just uploading new exult snapshot, will es need to be be recompiled too ?
[13:41:09] <Colourless> well, in theory the problem should effect es as well
[13:41:18] <Kirben> ok
[13:48:45] <wjp> Colourless: that GetShortPathName behaviour was probably Win98-specific, right?
[13:49:06] <Colourless> has to be
[13:49:17] <Colourless> didn't have any effect here on XP
[13:49:18] <wjp> silly that these things aren't documented in MSDN
[13:49:46] <wjp> hm, did you try on a FAT32 partition, btw?
[13:49:48] <Colourless> i'm gussing they used FindFirstFile when implementing GetShortPathName
[13:49:53] <Colourless> yeah i'm on fat32 :-)
[13:50:13] <wjp> (just wondering since the Wine code that handled this was in the FAT code)
[13:51:04] <Colourless> the documentation doesn't mention the effect of wildcards
[13:51:12] <wjp> yeah, I know :/
[13:51:15] <Colourless> however, the function isn't intended to be used with wildcards
[13:51:33] <Colourless> the bahaviour i guess is undefined
[13:59:48] <-- Kirben has left IRC ("System Meltdown")
[14:27:38] <Nadir> from the logs: Darke mentions that GCC 2.95.x isn't maintained anymore
[14:28:13] <Nadir> Not true. Work is still ongoing on that branch, as it is the only suported compiler for the Linux kernel. In fact a 2.95.4 will be out eventually
[14:28:26] <Nadir> in other news gcc 3.1 is out
[14:57:37] <wjp> PCH were delayed until past 3.1, right?
[15:08:04] <Nadir> yes
[15:10:23] <Colourless> so what is the reason why they are missing?
[15:12:02] <Nadir> http://gcc.gnu.org/ml/gcc/2002-02/msg00203.html
[15:14:33] <Colourless> seems to be just because of older, 'bad' code
[15:15:24] <Nadir> and swapping that code with something else is not an easy thing given the complexity of GCC
[16:47:39] <-- Nadir has left IRC ("Client Exiting")
[17:12:05] <Darke|afk> Nadir: According to all the bug closures on the gcc system, it looks like it's officially dead/unmaintained now: http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=2324 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=1647
[17:12:22] --- Darke|afk is now known as Darke
[18:53:49] <-- Colourless has left IRC ("time for me to go")
[20:38:15] --- Darke is now known as Darke|afk
[20:59:07] --- Darke|afk is now known as Darke
[21:23:09] * Darke shudders. He's just encountered the most horribly punny function name he's ever seen. It _must_ have been done deliberately, the function can't have any real use.
[21:39:18] * wjp kicks this number field
[21:39:38] * wjp seems to have miscalculated some prime ideals... ARGH
[21:39:57] * Darke watches the number field fly across the room and shatter on the far wall.
[21:40:14] * Darke guesses that is a Bad Thing. *grin*
[21:40:30] <wjp> well, let's just say that it's something you do quite early in the calculation :-)
[21:41:09] * Darke places a check mark beside the 'Bad Thing' option.
[21:42:05] <wjp> so now I can try to figure into which things this error spread...
[21:42:44] <-- Fingolfin has left IRC ("good night")
[21:42:59] <Darke> Is this a "Call in a nuclear strike because we're all going to die anyway" bad thing? Or just a normal "Run in circles scream and shout" bad thing? I need to know if I need to go grab my 'emergency' red pen to highlight it.
[21:43:31] <wjp> hm, closer to the latter I guess
[21:43:53] * Darke doesn't bother with the red highlight then. Not important enough.
[21:45:03] * Darke apologises for the surreal mood he's in again. The code he's working on is progressing far, far to easily. There's _got_ to be a problem somewhere in his logic. *grin*
[21:47:45] <wjp> ah ha! Found the miscalculation! woohoo :-)
[21:47:51] <wjp> (missed a square somewhere)
[21:48:49] <Darke> Cool.
[23:09:45] * Darke blinkblinks. A little over four hours intermittent work, and I have a decompiler stub integrated into disasm to decompile a 'simple' case of the calli opcode, which has been tested on the Item::bark intrinsic. This is just _so_wrong_.
[23:13:38] --> kappax has joined #exult
[23:13:59] <wjp> hi
[23:14:44] <-- kappax has left IRC (Client Quit)
[23:30:56] * Darke stares in puzzlement at to calls to urandom(), one's output feeding the other's 'limit'. Funky.
[23:31:42] <Darke> Hmm... A call to setFrame. It might be something to do with random fires or similar.