Timestamps are in GMT/BST.
| 00:02:11 | | Invisible has joined |
| 00:06:53 | | Invisible Quit (Ping timeout: 260 seconds) |
| 00:23:01 | | Watusimoto Quit (Ping timeout: 264 seconds) |
| 00:25:46 | | raptor Quit (Ping timeout: 258 seconds) |
| 00:55:05 | | Platskies Quit (Quit: Platskies) |
| 01:17:59 | | fordcars Quit (Quit: Page closed) |
| 01:24:56 | | Platskies has joined |
| 02:17:58 | | Watusimoto has joined |
| 03:02:36 | | Platskies Quit (Read error: Connection reset by peer) |
| 03:07:10 | | Platskies has joined |
| 03:10:21 | | Darrel Quit (Ping timeout: 272 seconds) |
| 03:10:47 | | Darrel has joined |
| 03:21:26 | | Platskies Quit (Quit: Sleep time…) |
| 03:25:40 | | LordDVG has joined |
| 03:29:02 | | LordDVG Quit (Remote host closed the connection) |
| 03:57:35 | | Platskies has joined |
| 04:11:44 | | Platskies has left #bitfighter |
| 05:05:11 | | LordDVG has joined |
| 05:23:17 | | Watusimoto Quit (Ping timeout: 240 seconds) |
| 06:50:46 | | LordDVG Quit (Remote host closed the connection) |
| 06:56:19 | | watusimoto has joined |
| 06:56:19 | | ChanServ sets mode +o |
| 06:57:37 | | watusimoto1 Quit (Ping timeout: 240 seconds) |
| 10:36:52 | | Xavi92 has joined |
| 10:57:09 | | Watusimoto_ has joined |
| 11:05:22 | | Watusimoto_ Quit (Ping timeout: 256 seconds) |
| 11:10:09 | | Xavi92 Quit (Remote host closed the connection) |
| 11:30:58 | | Xavi92 has joined |
| 12:07:17 | | LordDVG has joined |
| 12:11:56 | | Xavi92 Quit (Remote host closed the connection) |
| 12:56:48 | | Watusimoto_ has joined |
| 12:58:51 | | Invisible has joined |
| 13:33:15 | | raptor has joined |
| 13:33:15 | | ChanServ sets mode +o |
| 13:33:36 | raptor | good day! |
| 13:33:59 | raptor | oops... back in a bit... |
| 13:34:01 | | raptor Quit (Client Quit) |
| 14:02:46 | | raptor has joined |
| 14:02:47 | | ChanServ sets mode +o |
| 14:03:01 | raptor | good day! |
| 14:05:55 | | raptor Quit (Client Quit) |
| 14:21:21 | | Invisible Quit (Ping timeout: 260 seconds) |
| 14:22:24 | | LordDVG Quit (Remote host closed the connection) |
| 14:32:48 | | Watusimoto_ Quit (Ping timeout: 250 seconds) |
| 15:06:40 | | Canseco has joined |
| 15:57:10 | | LordDVG has joined |
| 16:35:55 | | Canseco Quit (Read error: Connection reset by peer) |
| 17:03:48 | | raptor has joined |
| 17:03:49 | | ChanServ sets mode +o |
| 17:18:12 | raptor | hi again |
| 17:18:15 | raptor | watusimoto: are you around? |
| 18:02:26 | watusimoto | hi |
| 18:02:37 | watusimoto | I wasn't, but I am |
| 18:02:56 | watusimoto | hi raptor |
| 18:15:12 | raptor | hi watusimoto |
| 18:15:15 | raptor | still around? |
| 18:16:40 | raptor | i keep missing you, sorry |
| 18:18:32 | watusimoto | hi, yes, somewhat |
| 18:18:37 | raptor | ah ha! |
| 18:18:43 | watusimoto | so we meet again! |
| 18:19:02 | raptor | I have the merge stuff completed |
| 18:19:07 | watusimoto | great! |
| 18:19:19 | raptor | and am ready to merge with what you pushed most recently |
| 18:19:23 | watusimoto | ok |
| 18:19:29 | watusimoto | those were pretty modest changes |
| 18:19:40 | raptor | I just wanted to check - do you have anything else coming in soon? |
| 18:19:56 | watusimoto | nothing worth waiting for/can't be redone if need be |
| 18:19:58 | raptor | because when I do this push, i'd like you to work off of it |
| 18:20:06 | raptor | ok |
| 18:20:08 | watusimoto | ok, go for it |
| 18:20:12 | raptor | ok great |
| 18:20:19 | raptor | that's all, then.. glad I caught you |
| 18:20:25 | watusimoto | There is one thing we need to discuss |
| 18:20:39 | watusimoto | a recent commit had a comment with your name in it |
| 18:20:49 | watusimoto | and a line marked with a bunch of xxxxxx's |
| 18:21:04 | raptor | oh? i didn't see that |
| 18:21:07 | raptor | i saw the xxxxx one |
| 18:21:11 | watusimoto | no worries. the situation is this |
| 18:21:25 | watusimoto | we have a lua function to find objects |
| 18:21:37 | watusimoto | you can optionally pass a table to save a tiny bit of overhead |
| 18:21:49 | watusimoto | we need to decide how this should work; either |
| 18:21:59 | watusimoto | 1) the table should be cleared and then filled |
| 18:22:01 | watusimoto | or |
| 18:22:15 | watusimoto | 2) the table should be appended to, like our fillVector system |
| 18:22:31 | raptor | is that that serious bug you found? |
| 18:22:33 | watusimoto | right now it does a third thing that I am delcaring The Wrong Thing. |
| 18:22:38 | raptor | hah |
| 18:22:38 | watusimoto | no |
| 18:22:42 | watusimoto | this is the mild one |
| 18:23:12 | watusimoto | the serious bug was that objects weren't being found |
| 18:23:13 | raptor | huh, i thought it did #2 |
| 18:23:26 | watusimoto | the tests you wrote suggested #2 |
| 18:23:31 | watusimoto | and the tests did work at one point |
| 18:23:53 | watusimoto | what happens now is that the table is refilled without clearing |
| 18:23:53 | raptor | i remember the function was built to be like #2 for performance reasons, because it could be called multiple times each tick |
| 18:24:18 | raptor | "refilled without clearing" <-- how does that manifest itself |
| 18:24:22 | watusimoto | that is, if the table had 4 items, and you are finding 2, slots 1 and 2 get overwritten, and 3 and 4 don't |
| 18:24:33 | watusimoto | so you still have a table with 4 items |
| 18:24:42 | raptor | oh yuk |
| 18:25:00 | watusimoto | The Wrong Thing. It must have gotten broken along the way. perhaps by me |
| 18:25:01 | raptor | that's The Wrong Thing |
| 18:25:17 | watusimoto | but before I do anything, I wanted to check in with you about what it should do |
| 18:25:23 | raptor | i believe #2 |
| 18:25:38 | watusimoto | so I thik it did #2 as well, but I doubt anyone uses it in any way that it matters |
| 18:25:45 | raptor | #1 incures some overhead which we I believe we do not want |
| 18:25:58 | raptor | now that you mention it - i remember fordcars complaining about this method |
| 18:25:59 | watusimoto | because if you want to find multiple things, you just pass multiple object types |
| 18:26:20 | watusimoto | I think #1 would be better; I don't think there is any overhead in practice |
| 18:26:36 | raptor | if #1, then there's no point in passing it a table |
| 18:26:39 | watusimoto | I think in practice, if we do #2, users will clear the table first, incurring the overhead |
| 18:26:42 | watusimoto | not true |
| 18:26:44 | raptor | just return a new table |
| 18:26:51 | watusimoto | if you pass a table, you don't need to build a new one |
| 18:26:51 | raptor | no? |
| 18:27:57 | watusimoto | the reason for passing a table is if you are searching for objects every tick, or perhaps multiple times (looking for bullets in different directions, for example), reusing the table, even in #1, avoids the garbage collection associated with creating tons of objects |
| 18:28:40 | watusimoto | if the c++ code clears the table, it's more-or-less the same as if the lua code cleared the table (I assume)... but creating a new table (either in lua or c++) incurs more penalty |
| 18:28:52 | watusimoto | it would be useless to create a table then pass it to c++ |
| 18:29:04 | watusimoto | but if you reusue the table every tick, that's where you save |
| 18:29:10 | watusimoto | but the table has to get emptied somehow |
| 18:29:28 | watusimoto | otherwise you have last tick's results in addition to this tick |
| 18:29:39 | watusimoto | 's results, and some of those references may be stale |
| 18:30:11 | | amgine123 has joined |
| 18:30:13 | watusimoto | I think #1 is best, but could live with #2. #3 is just stupid. |
| 18:30:20 | amgine123 | hello |
| 18:30:25 | watusimoto | hi |
| 18:30:34 | amgine123 | whats #1 #2 and #3 ? |
| 18:30:45 | amgine123 | jsut getting up to pace on whats going on |
| 18:30:47 | watusimoto | long story about a very techincal detail |
| 18:31:02 | watusimoto | you can look at the logs; it probably won't be interesting |
| 18:31:49 | amgine123 | btw is it possible to change a equation in the form of A(B^X) to (A/B)^ X |
| 18:31:53 | raptor | hmmm |
| 18:32:10 | watusimoto | amgine123: http://pastie.org/9763499 |
| 18:32:31 | amgine123 | so like 10x^2 to somthing like A/B ^ X |
| 18:32:41 | watusimoto | the (only) advantage of #2 is it's how our c++ code works |
| 18:33:14 | raptor | do we *know* that clearing a table is better than creating one? |
| 18:33:26 | watusimoto | clearing incurs no gc overhead |
| 18:33:34 | raptor | is there ever a case were we want to just append? |
| 18:33:36 | watusimoto | and that's what was killing us before |
| 18:33:41 | watusimoto | I don't think so |
| 18:33:53 | watusimoto | even in the C++ code, we only do so in one or two places |
| 18:34:15 | watusimoto | I mean if you wanted to search two different rectangles and combine the results, maybe |
| 18:34:35 | amgine123 | what are you using that parciular section of lua for |
| 18:34:50 | watusimoto | amgine123: bots finding objects |
| 18:35:05 | amgine123 | oh then #1 is definitly better |
| 18:35:53 | watusimoto | I beleive the originally implemented logic was #1, and I probably even voted for it |
| 18:36:20 | watusimoto | I now think #2 is marginally better because it takes the load off the bot programmer to clear the table |
| 18:36:40 | watusimoto | I doubt it would affect any existing bots, but if we changed, there is always that risk |
| 18:36:51 | amgine123 | yeah #2 is more user friendly |
| 18:37:43 | amgine123 | Use Pastie in your quest to save humanity, not in your evil plots to take over the world! >> guess we cant use pastie since bitfighter is polybuis |
| 18:37:49 | amgine123 | ^_^ |
| 18:38:15 | amgine123 | have you ever heard of the curse of oak island btw |
| 18:38:29 | amgine123 | theere is a show on history channel about it im obessed with it |
| 18:38:39 | amgine123 | my father thinks its a big hoax |
| 18:38:46 | watusimoto | amgine123: send me a link |
| 18:40:08 | amgine123 | there is this treasure buried on this one island thats has misllions but its booby trapped and no one can gety legend also says 7 people will die before anyone can get it |
| 18:40:13 | raptor | ok, we clear the table in c++ |
| 18:40:15 | raptor | i'm on board |
| 18:40:23 | amgine123 | 'and 6 epople have died so far trying to get it |
| 18:40:33 | watusimoto | what do you mean "we clear the table in c++"? |
| 18:40:33 | amgine123 | raptor i think #2 is better its more user friendly |
| 18:40:43 | watusimoto | I think it is |
| 18:41:25 | amgine123 | problem is taking shortcuts when there is a superior way can cause serious headach later |
| 18:42:56 | amgine123 | raptor I really im leaning towards # 2 but its your call |
| 18:43:15 | amgine123 | you want bitfighter to be user friendly ;) |
| 18:44:10 | watusimoto | reality tv! |
| 18:51:59 | raptor | i think we unknowningly switch 1 and 2 in our conversation, but if the option of auto-clearing the table is the good one, then I agree |
| 18:52:48 | raptor | wait what? |
| 18:53:18 | raptor | i'm having a hard time filtering out the noise; watusimoto, which option is the one you want, without saying the numbers? |
| 18:54:46 | watusimoto | I vote we clear the table before filling it |
| 18:54:54 | raptor | yes, ok |
| 18:54:59 | watusimoto | you too? |
| 18:55:06 | raptor | that was #1 above |
| 18:55:09 | watusimoto | oops |
| 18:55:18 | raptor | and yes, i agree - if we do the clearing in c++ (Lua C API) |
| 18:55:23 | watusimoto | yes, ok |
| 18:55:29 | raptor | which i what I think you meant, too |
| 18:56:05 | watusimoto | one other quick thing -- do you know how to do that? I did a quick search and came up dry, but I find most of the lua docs rather hard to grok. If you don't know, don't worry; it's not hard |
| 18:56:18 | watusimoto | I'll also update the tests and documentation |
| 18:56:33 | raptor | I would have to research again... the Lua docs aren't the clearest reading |
| 18:56:38 | watusimoto | amen to that! |
| 18:56:50 | watusimoto | but I'll do the research unless you atually want to |
| 18:58:15 | raptor | i suspect there is a simple one-line shortcut, but i'm not sure |
| 18:58:51 | raptor | I want to complete this merge... you're not working in code right now are you? |
| 19:03:56 | raptor | uh actually... isn't clearing a Lua table the same as iterating through it setting all items to nil? |
| 19:12:49 | | LordDVG Quit (Remote host closed the connection) |
| 19:12:54 | raptor | could that be more expensive than table construction? |
| 19:14:07 | | fordcars has joined |
| 19:19:29 | raptor | gotta go! |
| 19:19:33 | | raptor Quit () |
| 19:25:04 | | BFLogBot Commit: 35d71099d2 | Author: buckyballreaction | Message: Merge with Watusimoto's latest changes, before he does the crazy merge |
| 19:25:05 | | BFLogBot Commit: 1f9b46ebdd | Author: buckyballreaction | Message: Merge in 019d changes |
| 19:25:07 | | BFLogBot Commit: e9c068fed3 | Author: buckyballreaction | Message: Merge the two great merges |
| 19:25:08 | | BFLogBot Commit: 7016576e38 | Author: buckyballreaction | Message: Merge watusimoto's latest test fixes |
| 19:26:41 | | BFLogBot ok watusimoto, raptor has finished committing his merge work. You're good to go if you work off of the latest tip. |
| 20:22:17 | amgine123 | reality tv what ? |
| 20:38:41 | | Watusimoto_ has joined |
| 20:40:56 | | Invisible has joined |
| 21:06:46 | | Invisible1 has joined |
| 21:09:13 | | Invisible Quit (Ping timeout: 260 seconds) |
| 21:12:57 | | Invisible1 Quit (Ping timeout: 240 seconds) |
| 21:24:16 | | Invisible has joined |
| 21:27:55 | watusimoto | your show the curse of oak island |
| 21:32:37 | | Invisible Quit (Ping timeout: 240 seconds) |
| 21:36:52 | | raptor has joined |
| 21:37:04 | | ChanServ sets mode +o |
| 21:37:04 | raptor | ok, i did research into table.clear |
| 21:38:08 | fordcars | It seems to clear tables |
| 21:38:10 | | Invisible has joined |
| 21:38:39 | raptor | we build our own function for it in lua_helper_functions.lua |
| 21:39:00 | raptor | and it just iterates all entries and set them to nil |
| 21:39:10 | raptor | which then frees up the objects for GC |
| 21:39:10 | fordcars | Oh |
| 21:39:22 | raptor | (in response to a previous conversation with watusimoto) |
| 21:39:55 | fordcars | Knew that ;) |
| 21:42:26 | raptor | LuaJIT 2.1 (experimental, not yet released) added an efficient table.clear optimized for speed: http://repo.or.cz/w/luajit-2.0.git/commitdiff/4593fb5e29adc09cd53beaba8777f5656434c08d |
| 21:42:49 | raptor | see the description in the first file |
| 21:47:44 | raptor | i wonder if we shouldn't set up our own test cases to actually prove our ideas about performance |
| 21:52:45 | watusimoto | heading out... but it would be easy to test -- fix the function, then write a lua test that runs 10000x passing a table and 10000x not passing a table. easy! |
| 21:53:04 | raptor | there would be at least 3 tests |
| 21:53:37 | raptor | clear the table in lua, clear it in the c++, new table each tick in Lua, new table in c++ |
| 21:53:41 | raptor | 4 tests |
| 21:54:19 | watusimoto | talk to you later! |
| 21:54:33 | raptor | later |
| 21:54:47 | | watusimoto Quit (Read error: Connection reset by peer) |
| 21:56:45 | | raptor Quit () |
| 23:20:46 | | Watusimoto_ Quit (Ping timeout: 244 seconds) |
| 23:23:59 | | Invisible Quit (Ping timeout: 250 seconds) |
| 23:48:01 | | Watusimoto has joined |
| 23:53:50 | fordcars | Night! |
| 23:53:52 | | fordcars Quit (Quit: Page closed) |
| 23:54:35 | | Invisible has joined |