[01:00:10] --> wjp has joined #exult
[01:00:14] <wjp> hi
[01:00:14] --- ChanServ gives channel operator status to wjp
[01:00:48] * wjp notices unread-message-count of cvs-logs folder
[01:00:57] <wjp> Fingolfin: been working on MacOS classic? :-)
[01:01:08] <wjp> hmm... nm...
[01:01:21] <Fingolfin> no :)
[01:01:23] <wjp> looks like cvs-logs (finally) handled the backlog
[01:01:33] <Fingolfin> SF has site wide ML problems
[01:01:38] <Fingolfin> actually, they had two :)
[01:02:09] <Fingolfin> see my last post to exult-general
[01:07:10] <wjp> omg... nice post in the "SI and BG crash" thread
[01:08:12] <Fingolfin> ohh, right, we have a forum
[01:08:17] * Fingolfin goes there for the first time since llooooong ago
[01:08:18] <wjp> *grin*
[01:10:15] <Fingolfin> aaarrghh
[01:10:23] <Fingolfin> and that in a forum post, lol :)
[01:10:45] * wjp just 'shortened' the message 'slightly'
[01:16:18] <-- MiniMe has left IRC (capek.openprojects.net irc.openprojects.net)
[01:16:18] <-- matto has left IRC (capek.openprojects.net irc.openprojects.net)
[01:16:18] <-- Fingolfin has left IRC (capek.openprojects.net irc.openprojects.net)
[01:21:35] --> Fingolfin has joined #exult
[01:21:35] --> matto has joined #exult
[01:21:35] --> MiniMe has joined #exult
[01:22:47] <wjp> hmm... have to get up in 6 hours
[01:24:11] <Fingolfin> that reminds me of last thursday
[01:24:25] <Fingolfin> when I came home and had to get up at that time to drive my mom to work =)
[01:24:32] <wjp> :-)
[01:24:38] <wjp> after LotR?
[01:24:55] <Fingolfin> aye :) well I was lieing, I slept 2 hours actually
[01:24:59] * wjp should go see that sometime soon
[01:26:39] <wjp> liked LotR, btw?
[01:27:17] <Fingolfin> yes I liked it. it is different from the book, but in most cases these were changes that I could accept
[01:27:46] <Fingolfin> my cousing OTOH was disappointed
[01:27:48] <Fingolfin> cousin even
[01:27:55] <Fingolfin> so you see opinions differ :)
[01:38:03] <wjp> I've been working on the U8 graphics/map format a bit more this morning
[01:38:13] <wjp> I couldn't find the shape dimensions anywhere...
[01:38:19] <Fingolfin> the mapviewer thingy? :)
[01:38:20] <Fingolfin> hm
[01:38:34] <wjp> ...until I figured out that the 'origin' (same as U7) was always at the same point of the enclosing box
[01:38:59] <wjp> ...so you could calculate the dimension from the enclosing 2D box and the angles of the axes :-)
[01:39:47] <wjp> now I just need to find a nice comparison function for shapes
[01:39:58] <wjp> my last one wasn't transitive... caused a nice infinite loop... oops :-)
[01:42:15] <Fingolfin> he =)
[01:43:37] <wjp> anyway... I'm going to bed now
[01:43:42] <wjp> goodnight
[01:43:53] <-- wjp has left IRC ("[x]chat")
[02:06:56] <-- Fingolfin has left IRC ("night")
[08:49:33] --> Wumpus has joined #exult
[08:49:47] <Wumpus> `lo lo
[08:54:30] <Wumpus> hehe
[08:57:29] <Wumpus> oh well, i'm not on my regular isp atm, and i've got some real bug hunting to do; I'll be back if my normal isp works later :) (with a slew of shiny new bug reports, "hopefully" (for lack of a better word) )
[08:57:36] <-- Wumpus has left IRC ("Ouch")
[09:26:17] --> Darke has joined #exult
[09:26:17] --- ChanServ gives channel operator status to Darke
[11:26:01] --> Fingolfin has joined #exult
[11:26:25] --- ChanServ gives channel operator status to Fingolfin
[11:40:49] --> Wumpus has joined #exult
[11:41:14] * Wumpus forces fluff down darke's throat :)
[11:41:32] * Darke automatically looks innocent.
[11:49:01] * Fingolfin watches Darke looking innocent while swalloing the fluff
[11:49:28] <Fingolfin> Wumpus: ya know, you really shouldn't do that
[11:53:28] * Darke innocentfluffs, and wonders what Wumpus really shouldn't do.
[12:26:33] <Wumpus> fingolfin- hmm?
[12:27:47] <Fingolfin> all the fluff will cause him to become totall bloated, do we want that? :)
[12:36:44] * Darke innocentfluffs and happyfluffs and flufffluffs and... no, you don't want to see that fluff-fluffs..
[12:44:53] <-- Wumpus has left IRC ("sleep time...")
[12:54:12] --> Darkatom has joined #exult
[12:58:10] * Darke bows. "Hello."
[12:58:33] <Darkatom> Hello
[13:29:44] <-- Fingolfin has left IRC ("l8r")
[13:59:08] <-- Darkatom has left IRC ("-")
[15:44:16] --> wjp has joined #exult
[15:44:16] --- ChanServ gives channel operator status to wjp
[15:44:20] <wjp> hi
[15:44:36] * wjp looks at time
[15:44:56] <wjp> Darke: Merry Christmas :-)
[15:44:58] * Darke bows. "Hello. Happy Christmas/SirIsaccmas." <grin>
[15:45:11] <wjp> sirwho?
[15:45:19] <Darke> s/Isacc/Isaac/
[15:45:26] <Darke> [01:38:16] WALLOPS from firstname.lastname@example.org : Hi all. Depending on where you are in the world, it's either the 24th or the 25th. As you know, December 25 is a worldwide holiday, the commemoration of Sir Isaac Newton's Birthday. Have a slice of apple pie, relax, and enjoy a bit of inertia. Have a great SirIsaacmas! :)
[15:45:40] <wjp> lol
[15:46:26] * Darke thought that, that was rather... appropriate. <grin>
[15:47:27] * Darke wonders if he's rather... sad. Sitting on an almost empty irc channel at 2am on SirIsaacmas morning. <grin>
[15:48:42] <wjp> :-)
[15:52:45] * Darke considers the only thing he wants for SirIsaacmas is the solution to this dumb bug he's been working on for ages.
[15:52:59] <wjp> if (a && !a) ?
[15:53:06] * Darke nods.
[15:53:20] <wjp> do you have an intrinsic function in which it occurs?
[15:54:59] <Darke> Yep. 402, except it's huge. All the 'smaller' usecode functions I've found (most don't have the required 'complexity' of ((a + b) && (!(a + b))) though), I can't replicate it in. It's weird.
[15:55:41] <wjp> 402 hex?
[15:55:42] <Darke> It's just after offset 0189. I can cut&paste the exact bits of code if you wish.
[15:55:56] <wjp> BG?
[15:56:12] <Darke> Yep, and yep. It's Spark's code.
[15:56:37] <wjp> how do I call ucxt for this, btw? "ucxt -fz 402" ?
[15:56:46] <Darke> Yep.
[15:57:26] <wjp> hmm, the two statements after label0402_0173, right?
[15:57:45] <Darke> Yes. Also there.
[15:58:13] <Darke> The problem is, in 092a, it 'works': if(!((var0003 + var0000) < pushi(0001))) goto labelFunc_003F;
[16:01:49] <-- matto has left IRC (capek.openprojects.net irc.openprojects.net)
[16:01:49] <-- MiniMe has left IRC (capek.openprojects.net irc.openprojects.net)
[16:01:49] <-- Darke has left IRC (capek.openprojects.net irc.openprojects.net)
[16:01:49] <-- wjp has left IRC (capek.openprojects.net irc.openprojects.net)
[16:02:10] --> wjp has joined #exult
[16:02:10] --> Darke has joined #exult
[16:02:10] --> matto has joined #exult
[16:02:10] --> MiniMe has joined #exult
[16:02:57] <wjp> hmm... changing that #if 0 to #if 1 (the debugging thing at the top) caused lots of compile errors
[16:03:40] <Darke> Yes. I've fixed them in my current copy. Should I commit? There will only be minor changes I think.
[16:04:05] <wjp> sure. bugfixes good :-)
[16:05:23] <Darke> The only thing is I've 'broken' -fz output slightly, it adds a 'partial' traceback of the components of a complex expression, which is probably going to be minorly deceptive to at the very least you looking at it. <grin>
[16:06:05] <Darke> For example, this is how a bit of code looks to me:
[16:06:13] <Darke> label0402_0189:
[16:06:13] <Darke> UcFlag[003E]
[16:06:13] <Darke> (!UcFlag)
[16:06:13] <Darke> (UcFlag && (!UcFlag))
[16:06:13] <Darke> if(!(UcFlag && (!UcFlag))) goto labelFunc_01A4;
[16:06:23] <wjp> brb
[16:06:29] <Darke> You, theoretically, should only be seeing the first two and last line currently.
[16:12:07] <wjp> only the first one and last, actually
[16:13:19] <Darke> Weird, looks like I must have fixed another bug. <grin>This is technically exactly what you should be seeing:
[16:13:20] <Darke> label0402_0189:
[16:13:20] <Darke> UcFlag[003E]
[16:13:20] <Darke> if(!(UcFlag && (!UcFlag))) goto labelFunc_01A4;
[16:13:39] <wjp> oh... wait... I missed the label
[16:13:49] <wjp> first two lines in that case :-)
[16:13:50] <Darke> The UcFlag[003E] is what is ment to go instead of the first UcFlag.
[16:14:37] * Darke grins.
[16:15:03] * Darke will do a commit in the next few minutes.
[16:17:28] <Darke> 2001-12-24 Patrick Burke <email@example.com>
[16:17:28] <Darke> * usecode/ucxt/*: Removed bugs from debugging statments.
[16:18:21] * Darke considers it a bit ironic that his debugging statements had bugs of their own. <snicker>
[16:18:35] <wjp> aye :-)
[16:22:00] <Darke> Ok. I don't suggest you actually alter the #if 0 to #if 1. It produces 143000+ lines of text when using `ucxt -fz 402`. <grin> There's three commented out #defines below that #if 0 statement, uncomment any of those three (I suggest one at a time <grin>) for a more managable output (6000+ lines with all 3 uncommented).
[16:22:27] <wjp> 143K.. hmm... kind of a lot :-)
[16:23:14] <Darke> Yes. <grin> The DEBUG_READ*, IIRC is the one that's producing a large chunk of that.
[16:27:53] <wjp> ok, works now
[16:30:31] * Darke nods. Cool.
[16:31:53] * wjp digs his way through lots of ()'s
[16:33:23] * Darke thinks there's going to be a global shortage of ()'s by the time ucxt is 'finished'.
[16:43:25] <wjp> there are several "did not find all opcode parameters" messages too, btw
[16:48:53] <Darke> <nod> They are normal. If a 'value' has been pushed onto the stack in another 'goto/label block', it's currently not visible in parse_ucs_pass2b. <grin> And that, is exactly where things get complicated.
[16:51:10] * wjp hmmms
[16:51:29] <wjp> yes, I can imagine that would get pretty complex
[16:57:34] <Darke> It's not too bad, once you've got 'flow control' sorted out, and can tell which blocks are 'if's which are 'while's. So you can say "There is only one path that goes through here, so there for this 'push' must be associated with this 'pop'." But until then, you need a mind to work it out. <grin>
[16:57:47] <wjp> vec.rend() == 'reverse end' ?
[16:57:50] <wjp> :-)
[16:58:16] <Darke> Yep. <grin> Remember we're going through the array backwards. They're all reverse_iterators we're dealing with.
[16:58:24] * wjp nods
[16:58:37] <wjp> I'm starting to get why it should work
[16:58:48] <wjp> next step: why doesn't it work? ;-)
[16:59:13] * Darke grins. "Good. At least I know my theory of 'how it should work' isn't completely off the wall."
[17:00:31] <wjp> ok... when the parameters for the 'not' are processed, it really should reach the 'current->second = true' for current=='pushf 64'
[17:01:03] <wjp> ...but apparently it doesn't
[17:01:13] <wjp> (or something else is wrong...)
[17:01:54] * Darke nods.
[17:02:23] <wjp> the line "P-4 018C: pushf flag:" occurs twice
[17:02:53] <wjp> ...which is kind of strange, since immediately after that output, it's marked as used
[17:03:39] * Darke nods.
[17:09:07] <wjp> uh
[17:09:18] <wjp> if(current->second==false);
[17:09:18] <wjp> !?
[17:09:25] <wjp> what's that ; doing there?
[17:09:42] <Darke> It should be. <blink>
[17:11:41] <Darke> Scratch that. That entire line should't be there I don't think. I need to do some testing though.
[17:12:58] <wjp> where do you check if you're re-using an opcode then, if not there?
[17:15:57] <Darke> Nowhere at the moment I don't think. It used to be further down where it was calling itself recursivly. It _should_ be there, it's just breaking things severely at the moment, I'm in the process of trying to fix it. <grin>
[17:17:19] <Darke> Another test is needed down at 'if(opsneeded!=0)' too. That appears to be where the problem lies, it's a race condition.
[17:25:23] * Darke gets the feeling he's doing something very, very dumb somewhere.
[17:32:18] * wjp wonders why it infinite-loops when you re-enable that if(current->second==false)
[17:34:43] <wjp> hmm
[17:34:57] <wjp> could the parameter counting for the intrinsic calls be wrong?
[17:35:17] <wjp> I'm getting num_args == 2 for a remove_answer@01 call
[17:36:41] <wjp> shouldn't num_pop = -2 mean 'the value of the 2nd opcode param' ?
[17:36:52] <Darke> Weird. It's possible.
[17:37:04] <wjp> num_args = 0x100 - opcode_table_data[current->first->_id].num_pop;
[17:37:25] <wjp> just sets num_args to 2
[17:38:13] <Darke> Yes. There should be an additional -1 at the end of that line. I think.
[17:38:24] <wjp> shouldn't there be a lookup?
[17:39:15] <wjp> something like: offset = 0x100 - opcode_table_data[blah].num_pop; num_args = rawdata[this_opcode + offset];
[17:41:05] <Darke> No. I don't think so anyway. <grin> I'm half asleep at the moment, sorry.
[17:43:39] <Darke> Actually, your last line I think is correct.
[17:44:13] * wjp thinks so too
[17:44:31] <wjp> your -1 is correct too, btw
[17:44:35] <wjp> int offset = 0x100 - opcode_table_data[current->first->_id].num_pop - 1;
[17:44:36] <wjp> num_args = current->first->_params_parsed[offset];
[17:44:56] * Darke nods. Thanks. That's what I just wrote as well. <grin>
[17:45:00] <wjp> :-)
[17:45:11] <wjp> it still infinite loops though :/
[17:46:02] <Darke> Weird. 96 doesn't infinate loop, but 402 does.
[17:46:13] * wjp nods
[17:46:19] <wjp> around 2B6, right?
[17:46:34] * Darke nods.
[17:48:28] <wjp> 1 026E: calli remove_answer@01
[17:48:28] <wjp> 2 026B: pushs 09B8H
[17:48:28] <wjp> 3 026B: pushs 09B8H
[17:48:28] <wjp> 1 033C: pop [000B]
[17:48:51] <wjp> why does it suddenly jump back all the way to 33C there?
[17:50:12] <wjp> hmm, isn't "1" just used just after returning from recursion?
[17:51:13] <Darke> No idea. But if you comment the 'current->second=true;' line 323, it stops the infinate loop for me. <grin> It doesn't solve the problem but may give you a hint.
[17:51:45] <wjp> but then you stop marking anything as used?
[17:51:45] <wjp> that can't be good :-)
[17:52:10] <Darke> Yep. <grin>
[17:53:24] * Darke is just trying to attack the problem from an orthogonal direction. <grin> Can't have both of us doing exactly the same things.
[17:54:19] <wjp> heh :-)
[17:54:59] <wjp> hmm, 'cmps' is causing problems I think
[17:55:06] <wjp> it's not pushing anything, so it never gets set to used
[17:55:54] <wjp> that did it :-)
[17:56:37] <Darke> <earperk> Who? What? Huh? Where?
[17:56:50] <wjp> label0402_0189:
[17:56:50] <wjp> if(!(UcFlag[003E] && (!UcFlag))) goto labelFunc_01A4;
[17:56:57] * Darke did alter opcodes.txt to DTRT.
[17:57:24] <wjp> what do you mean?
[17:57:43] <Darke> Yay!
[17:57:49] <wjp> (ie. what did you alter?)
[17:58:19] <Darke> Changed column 9 (# of opcodes pushed) in CMPS to 1.
[17:58:40] <wjp> but it doesn't push anything, doesn't it?
[17:58:53] * wjp seems to be very lagged
[17:59:51] <Darke> <blink> Don't mind me. Completely confuzzled, ignore that last alteration.
[18:00:24] <wjp> this is what I changed:
[18:00:41] <wjp> removed the ';' after if(current->second==false)
[18:00:56] <wjp> added that offset thingie in function calls
[18:01:24] <wjp> added an "else current->second=true" to the "if(opcode_table_data[blah].num_push!=0"
[18:01:52] * Darke will grab a 'clean' copy from cvs and duplicate this.
[18:04:57] <wjp> round-trip min/avg/max/mdev = 6199.165/6742.241/8181.467/536.315 ms... yow
[18:05:18] <Darke> Umm.... ow.
[18:05:59] <wjp> hmm... my full upstream bandwidth is in use by my brother
[18:07:48] * wjp wonders if he can prioritize his own traffic somehow
[18:08:38] <Darke> IIRC there is a way, however I'm in a rather zombiefied state at the moment, and can't remember how. <grin>
[18:09:48] <wjp> I guess I'll look at some traffic-shaping-HOWTO's soon :-)
[18:10:41] <Darke> Ok. The changes seem to have uncovered an additional bug (or something), the SOMETHING_GOES_HERE that you get from function 96, shouldn't be there. <grin> Anyway, I think I shall wait until I'm awake to kill that bug. Thanks for the help.
[18:12:36] <wjp> sure, no problem. Thanks for writing it in the first place :-)
[18:13:27] <Darke> I will be really, _really_ happy when I don't have to look at this 100 or so lines of code again, after killing these last couple of bugs.
[18:13:34] <wjp> what is that SOMETHING GOES HERE, btw?
[18:14:37] <Darke> It's where the output routine expects a opcode to have an attached variable, and it doesn't, so it puts a nice big ALL_CAPS warning up for me to see.
[18:15:09] <wjp> I see
[18:15:22] * wjp looks at 0x96
[18:15:30] <Darke> unsigned int offset = 0x100 - opcode_table_data[current->first->_id].num_pop - 1;
[18:15:30] <Darke> num_args = current->first->_params_parsed[offset];
[18:15:37] * wjp looks at ucxt output
[18:15:58] <wjp> hm?
[18:16:03] <Darke> Oops. `demunge_ocstring` is the function that handles that. I don't know where the error is, and I don't intend to look for it at the moment. <grin>
[18:16:20] <Darke> (accidental cut&paste error)
[18:16:27] <wjp> ah, ok :-)
[18:17:03] * Darke needs to collapse into a ball and fall into a _deep_ sleep. <grin> "Feel free to examine the code and fix bugs without me. Night!"
[18:17:10] <wjp> night :-)
[18:17:16] <-- Darke has left #exult ()
[20:00:12] <-- wjp has left IRC ("[x]chat")
[23:14:15] --> MMe has joined #exult
[23:17:24] <-- MiniMe has left IRC (Ping timeout: 180 seconds)
[23:17:24] <-- MMe has left IRC (capek.openprojects.net irc.openprojects.net)
[23:17:24] <-- matto has left IRC (capek.openprojects.net irc.openprojects.net)
[23:39:24] --> matto has joined #exult
[23:39:53] <-- matto has left IRC (capek.openprojects.net irc.openprojects.net)
[23:40:33] --> matto has joined #exult