#bitfighter IRC Log

IRC Log for 2012-05-25

Timestamps are in GMT/BST.
00:03:50 raptor i can't believe how crazy this is to get to compile
00:03:54 raptor circular includes...
00:38:36 raptor Quit (*.net *.split)
00:44:03 raptor has joined
01:09:02 raptor Quit ()
04:48:46 raptor has joined
04:48:46 ChanServ sets mode +o raptor
05:33:03 raptor stacktrace of crash when adding s_bot now:  http://pastie.org/3963990
05:34:13 raptor why is the index counting down?
05:44:46 kodaws has joined
05:55:32 Watusimoto has joined
06:02:15 Watusimoto Quit (Ping timeout: 260 seconds)
06:03:51 raptor Quit ()
07:08:42 sam686 has left
07:52:22 kodaws Quit (Ping timeout: 248 seconds)
08:10:28 watusimoto has joined
08:10:28 ChanServ sets mode +o watusimoto
08:27:50 kodaws has joined
13:15:13 IAmBeard has joined
14:39:13 watusimoto Quit (Remote host closed the connection)
15:04:49 Watusimoto has joined
15:22:53 raptor has joined
15:22:53 ChanServ sets mode +o raptor
15:23:00 raptor morning!
15:30:43 raptor Watusimoto: when you call dumpTable() do you go backwards in indices?  e.g. -1, then -2, then -3, etc..
15:34:27 IAmBeard g'morning :)
16:38:33 watusimoto1 has joined
16:38:39 watusimoto1 hey there
16:38:46 raptor HI
16:39:00 watusimoto1 ok, I think I know the problem with luaW
16:39:13 watusimoto1 it's fixable, just not sure how
16:39:15 raptor did my trace help at all?
16:39:28 watusimoto1 I will try to do it tonight, but no promises
16:39:29 watusimoto1 no
16:39:38 watusimoto1 but the crash was not related
16:39:39 raptor those circular includes were killing me..
16:39:43 raptor ah ok
16:39:51 watusimoto1 it was a bug in the debugging code
16:40:00 watusimoto1 ironically
16:40:05 raptor ha!
16:40:13 raptor that was my guess
16:40:22 watusimoto1 anyway, I'm going to (quickly) explain the problem, so you can think it over, and we'll see later if we can find a solution
16:40:30 watusimoto1 We do a bunch of registrations like this:
16:40:31 raptor ok
16:40:31 watusimoto1 REGISTER_LUA_SUBCLASS(MoveObject, Item);
16:40:38 watusimoto1 and REGISTER_LUA_CLASS(MoveObject, Item);
16:40:44 raptor yes
16:40:52 watusimoto1 oops
16:40:58 raptor that second one looks wrong...
16:41:01 watusimoto1 and REGISTER_LUA_CLASS(Item);
16:41:03 watusimoto1 yes
16:41:09 watusimoto1 turns out the order is important
16:41:11 watusimoto1 I think
16:41:21 raptor as in you need to register the parents first?
16:41:23 watusimoto1 so before we can do REGISTER_LUA_SUBCLASS(MoveObject, Item), we have to have registered item
16:41:28 raptor ok
16:41:35 watusimoto1 and before we register item, we need to register anything that item depends on
16:41:37 watusimoto1 and so on
16:41:41 raptor ok
16:41:52 watusimoto1 pretty straightforward
16:42:12 raptor so we need a way to guarantee the parent is always registered first?
16:42:13 watusimoto1 currently, we register all the classes in arbitrary order, which is fine
16:42:27 watusimoto1 because they depend on nothing
16:42:37 watusimoto1 then the subclass declarations also get done, also in arbitrary order
16:42:42 watusimoto1 which is the problem
16:42:55 watusimoto1 so yes -- we need to order the subclasses so that they go in the proper order
16:43:09 watusimoto1 REGISTER_LUA_SUBCLASS(MoveObject, Item)
16:43:12 raptor ok
16:43:16 watusimoto1 REGISTER_LUA_SUBCLASS(Item, BfObject)
16:43:24 watusimoto1 REGISTER_LUA_SUBCLASS(MoveItem, MoveObject)
16:43:31 watusimoto1 REGISTER_LUA_SUBCLASS(TestItem, MoveItem)
16:43:33 raptor then we need a pre-registry registry that preps all the class by reordering them
16:43:41 watusimoto1 yes, probably
16:43:55 watusimoto1 so.  that needs to go in luaW, in the registrar class
16:44:08 watusimoto1 it's very straightforward in there, only like 10 lines of code
16:44:19 watusimoto1 just putting stuff into vectors, which are then processed
16:44:23 raptor yeah, looks good
16:44:44 watusimoto1 if you want to look at that, I won't do anything on that until I visit chat, if at all
16:45:04 watusimoto1 you can remove any debugging code from luaw -- if this is the problem, we won't need it
16:45:10 watusimoto1 and it's crashy in any event
16:45:18 watusimoto1 though I know the problem and can fix it
16:45:37 watusimoto1 so if you can figure out a solution, great, otherwise I'll take a look.  But i may only have like an hour
16:45:42 raptor do you want to keep the dump* methods?  because if so, they need to be removed from LuaObject
16:46:02 watusimoto1 if you remove them from luaWrapper, they can stay in luaObject, no?
16:46:07 raptor yes
16:46:14 watusimoto1 so you can just do that, if it's easier
16:46:17 raptor ok
16:46:25 watusimoto1 or hell, we can move them to luaWrapper
16:46:32 watusimoto1 anyway, I've got to run
16:46:42 watusimoto1 so I'll check in later
16:46:45 raptor well, my workaround was to make a new namespace LuaDebug and put them in lua.h
16:46:46 raptor ok
16:46:57 watusimoto1 saw that
16:47:20 raptor see you later
16:47:35 watusimoto1 we can probably cosolodiate much of luaObj and luaW later
16:48:18 watusimoto1 bye!
16:48:43 raptor bye
16:52:39 watusimoto1 Quit (Ping timeout: 260 seconds)
16:59:34 kodaws Quit (Read error: Connection reset by peer)
17:33:27 Watusimoto Quit (Ping timeout: 246 seconds)
18:34:25 LordDVG has joined
19:00:05 LordDVG Quit (Read error: Connection reset by peer)
19:00:47 LordDVG has joined
19:23:13 Watusimoto has joined
19:29:25 raptor hi Watusimoto
19:41:33 Watusimoto hi
19:41:44 raptor ok, so i did crazy stuff:
19:41:48 raptor http://pastie.org/3967736
19:42:14 raptor basically inserting the class registration into a map that sorts by class and parentclass
19:42:24 raptor but it doesn't sort properly
19:43:02 raptor some objects aren't being compared within the map and i'm not sure why
19:43:25 raptor the map has a key/value of:   compareKey, registerFunc
19:43:44 raptor compareKey is a pair<classname, parentClassname>
19:44:10 Watusimoto ok, looking
19:44:59 Watusimoto so sorting doesn't work, or it works, but lua is still broken?
19:45:17 raptor sorting works-ish
19:45:27 raptor because it isn't complete, lua is still broken
19:45:43 raptor my sorting works on half the objects properly, i think
19:45:53 raptor so it may be bad somewhere, but i'm not sure where
19:46:04 Watusimoto what are first and second?
19:46:43 raptor so the map looks like this:   map<pair<classname, parentClassname>, function>
19:46:59 raptor so the key is a pair of the class name and parent classname
19:47:06 raptor key.first = classname
19:47:08 Watusimoto fist = class, second = parent
19:47:13 raptor yes
19:48:07 raptor but i may be going about this entirely wrong...
19:48:07 Watusimoto so if sort returns true, a is before b?
19:48:10 raptor yes
19:48:34 Watusimoto the NUL checks look ok
19:48:51 Watusimoto strcmp check looks ok
19:51:04 raptor but only about half the classes are registered in order - it could be i'm iterating incorrectly, too
19:51:12 raptor but i don't know how else...
19:51:50 Watusimoto iterators... yuck!  :-)
19:52:16 Watusimoto so... what do you get?
19:52:45 Watusimoto half sorted; what does that mean?
19:52:48 raptor http://pastie.org/3967829
19:52:54 raptor is how they're registered
19:53:21 raptor and here is the comparator results when inserting:  http://pastie.org/3967833
19:53:43 raptor there are breaks in places,  like  Item never gets compared to BfItem
19:53:44 Watusimoto look mostly totally unsorted to me
19:53:53 Watusimoto asteroid is 2nd
19:53:59 raptor yeah well
19:54:15 raptor it does Item -> MoveItem -> MoveObject ok
19:54:24 Watusimoto could be luck
19:54:31 raptor true
19:55:49 Watusimoto so the map is maintained in a sorted manner?
19:55:55 raptor yes
19:56:05 raptor or at least that what all the docs say...
19:56:11 raptor i don't know how the iterator works
19:56:20 Watusimoto well, you should see lots of stuff being printed as you sort
19:56:23 Watusimoto so you should know
19:56:37 raptor sort is done on insert
19:56:52 raptor that second link above shows the sort
19:57:36 raptor anything without an r: true or false means it was sorted alphabetically
19:58:33 raptor maybe i need to keep a vector and do a sort after the fact..
19:59:30 Watusimoto so every insert gets sorted
19:59:40 raptor yes
19:59:43 Watusimoto and every sort iteration, aside from alpha sort, should
19:59:48 Watusimoto print an r: line
19:59:52 raptor i do
19:59:55 Watusimoto perhaps more than 1
20:00:01 raptor well, except for the last one
20:00:07 Watusimoto a: Ship, parent: MoveObject
20:00:07 Watusimoto b: SoccerBallItem, parent: MoveItem
20:00:25 Watusimoto which do you think you are inserting here?
20:00:50 Watusimoto maybe b?
20:01:08 Watusimoto maybe a is already in the map, then adding b?
20:01:09 raptor ok, i'll add the last sort print
20:01:22 Watusimoto better, print out what's getting added
20:01:32 Watusimoto so we can see what's going in in which order
20:01:47 Watusimoto and make sure it's bing sorted as we think it is
20:02:14 Watusimoto I don't even know how many comparisons are being generated by a particular insert
20:02:58 raptor muchos
20:04:23 Watusimoto the sort results look correct
20:04:24 raptor ok, here is better logging:  http://pastie.org/3967897
20:04:44 Watusimoto so
20:04:45 Watusimoto adding: SoccerBallItem, parent: MoveItem
20:04:48 Watusimoto no sort, good
20:04:49 raptor yes - the problem is that certain insertions aren't comparing all top elements
20:05:24 raptor don't ask me why some compares are run twice...
20:05:32 Watusimoto adding: Ship, parent: MoveObject
20:05:32 Watusimoto =======
20:05:32 Watusimoto a: Ship, parent: MoveObject
20:05:32 Watusimoto b: SoccerBallItem, parent: MoveItem
20:05:32 Watusimoto r: true
20:05:33 raptor quirk of the container, i think
20:05:34 Watusimoto =======
20:05:36 Watusimoto a: Ship, parent: MoveObject
20:05:38 Watusimoto b: SoccerBallItem, parent: MoveItem
20:05:41 Watusimoto r: true
20:05:43 Watusimoto mmmm
20:05:47 Watusimoto adding ship
20:06:03 Watusimoto did you log alpha sorting?
20:06:11 raptor yes, that is what it is doing
20:06:13 Watusimoto ok
20:06:26 raptor alpha sorting is the default when nothing else can be determined
20:06:32 Watusimoto right
20:06:51 Watusimoto so 2nd iter is ok, aside from double sort
20:07:49 Watusimoto you should dump the map after each iteration
20:07:56 raptor ok
20:08:02 Watusimoto so we can see what's ending up where
20:11:59 raptor ok, compiling...
20:12:21 raptor this will be noisy...
20:12:57 raptor Watusimoto: http://pastie.org/3967937
20:13:10 Watusimoto looking
20:15:13 Watusimoto take out the alpha sort
20:15:49 raptor ok
20:15:56 Watusimoto a: Asteroid, parent: MoveItem
20:15:56 Watusimoto b: Projectile, parent: BfItem
20:15:56 Watusimoto r: true
20:16:08 Watusimoto but asteroid isn't above projectile
20:16:31 raptor then what do i place in its stead?
20:16:51 Watusimoto uh
20:17:00 Watusimoto you have to return something, don't you
20:17:06 Watusimoto then leave it
20:17:12 Watusimoto but there's something wrong here
20:17:26 Watusimoto look at asteroid
20:17:55 Watusimoto the first comparison tells it that asteroid is above projectile
20:18:20 Watusimoto that asteroid is above everything, really
20:18:37 raptor it is, alphabetically
20:18:51 Watusimoto we have a pre-sorted map
20:18:55 Watusimoto we add asteroid
20:19:07 Watusimoto if asteroid is above the first item, it can really stop there, no?
20:19:28 Watusimoto because the entire list is sorted
20:19:48 Watusimoto the problem is that, I think, we don;t have a list
20:19:55 Watusimoto we have a series of trees
20:19:57 raptor explain?
20:20:00 raptor ah yes
20:20:10 Watusimoto some of the trees are unrelated
20:20:22 Watusimoto yet we're treating them as if they can all be ordered somehow
20:20:28 Watusimoto when they can't
20:20:52 raptor maybe something in the hierarchy is broken somewhere...
20:20:58 Watusimoto no
20:21:03 Watusimoto I've checked that
20:21:09 Watusimoto look at the comparisons for asteropid
20:21:11 raptor because there is no Item <-> BfItem comparison
20:21:18 Watusimoto all are correct
20:21:24 raptor yes
20:21:29 Watusimoto sticking with asteroid for a second
20:21:37 raptor ok
20:21:40 Watusimoto no important comparisons are made
20:21:47 Watusimoto everythign compared is irrelevant
20:22:08 Watusimoto if I gave you a list of sorted numbers and asked you to insert a new one, you could do that easily
20:22:28 Watusimoto compare your # with the first item on the list, and either insert or compare further
20:22:55 Watusimoto if, however, I gave you a list of numbers, letters, and colors on the spectrum, and handed you "violet", how would you insert that?
20:23:03 Watusimoto compare violet to 3
20:23:04 raptor yes
20:23:11 raptor ok
20:23:18 Watusimoto ok, I arbitrarily tell you violet comes first
20:23:31 Watusimoto so you insert that at the head of the list
20:23:46 Watusimoto when in fact, you need to find the other colors and make your comparisons there
20:24:09 Watusimoto the map thinks it is a sorted, ordinal list
20:24:11 Watusimoto but it's not
20:24:24 Watusimoto so it gets confused and hands us garbage
20:24:43 Watusimoto it doesn't know it needs to keep searching until it finds something related to the asteroid, then insert
20:25:11 raptor ok recursive search...
20:26:18 Watusimoto I don't think so
20:26:41 raptor qsort on a vector
20:26:45 raptor allows -1, 0, 1
20:27:52 Watusimoto I think we're going to need to do this in at least 2 passes
20:28:25 Watusimoto let's jhust take it in order and see
20:28:39 Watusimoto adding: SoccerBallItem, parent: MoveItem
20:28:51 Watusimoto first item, stick it anywhere
20:29:05 Watusimoto adding: Ship, parent: MoveObject
20:29:13 Watusimoto 2nd -- unrelated to first
20:29:41 Watusimoto should it go in the same list?
20:30:03 Watusimoto oh hell, stick it anywhere
20:31:09 Watusimoto adding: Robot, parent: Ship
20:31:27 Watusimoto compare with ship, stick it under
20:31:47 Watusimoto so we have
20:31:47 Watusimoto Ship
20:31:47 Watusimoto Robot
20:31:47 Watusimoto SoccerBallItem
20:31:48 Watusimoto so far so good
20:31:55 Watusimoto adding: Projectile, parent: BfItem
20:32:11 Watusimoto adding: Burst, parent: MoveItem
20:32:18 Watusimoto these go anywhere
20:32:24 Watusimoto take that back
20:32:29 Watusimoto start iterating down the list
20:32:41 Watusimoto this won't work
20:33:11 Watusimoto if your hiearchy is asteroid is a move item is a moveobject is a item is a bfobject
20:33:26 Watusimoto and you get asteroid first
20:33:29 Watusimoto that goes on top
20:33:32 raptor yep
20:33:35 Watusimoto then you get item
20:33:39 Watusimoto that goes second
20:34:03 Watusimoto then you get moveitem
20:34:12 Watusimoto that goes third (it appears unrelated to other entries)
20:34:27 Watusimoto so our list looks like asteroid item moveItem
20:34:40 Watusimoto then we get moveObject
20:34:44 Watusimoto where does that go?
20:34:47 LordDVG Quit (Remote host closed the connection)
20:35:04 Watusimoto you have to redo the whole list
20:35:33 Watusimoto mo is an item, so you put before item
20:35:43 Watusimoto (sorry, this is all reversed)
20:36:07 Watusimoto so you get asteroid moveobject item moveitem
20:36:28 Watusimoto how does moveitem get to the right place?
20:37:59 raptor are you asking within the context of std::map?
20:41:21 Watusimoto or really any context
20:41:33 Watusimoto once the item is in place, how do you know it needs to be moved?
20:41:45 raptor so the issue is that we have asteroid as a top level element, and it stays put
20:41:53 Watusimoto yes
20:42:12 Watusimoto but I think it's because we are approaching the problem wrong
20:42:18 raptor yes
20:42:24 Watusimoto we have a tree
20:42:30 Watusimoto or a series of trees
20:42:43 raptor and we're comparing only the first level, isntead of all levels we have
20:42:48 Watusimoto (though we could perhaps make everything inerit from a single dummy class to force it to be a tree)
20:43:11 raptor or maybe make sure BfItem goes in first?
20:43:11 Watusimoto well, we also get objects and might not have enough info to know where they go
20:43:21 Watusimoto we can't control the order
20:43:35 Watusimoto we might get that one last
20:44:28 Watusimoto as we get new classes, we could add them to a regular vector
20:44:31 Watusimoto unsorted
20:44:34 raptor i'm testing something evil...
20:44:43 Watusimoto then build a tree from the classes we have
20:44:54 Watusimoto repeating the exercize for each new class
20:45:56 Watusimoto ok
20:46:43 Watusimoto I know how to do it if we care nothing for efficiency
20:46:47 raptor i'm doing a qsort on a vector after all objects are entered
20:46:55 raptor we don't care about efficiency much do we?
20:46:57 Watusimoto how do you know they're all entered?
20:47:19 Watusimoto and the qsort won';t work anyway
20:47:20 raptor because registerClasses(lua_State *L) is called once after they're added to the vectors
20:47:30 Watusimoto true
20:47:52 Watusimoto knowing that, my method isn't too bad
20:48:20 Watusimoto my idea is this
20:48:49 Watusimoto when we have all the classes, we know that every class is either a root or a child of another class
20:48:54 Watusimoto we know all the roots
20:49:04 Watusimoto so we create one vector for each root
20:49:13 Watusimoto then we start with the children
20:49:31 Watusimoto take each child, look at ll the possible roots, see if we can find a parent
20:49:45 Watusimoto if so, insert it into the parent's vector just below the parent
20:49:57 Watusimoto if not, advance to next item
20:50:01 Watusimoto next child
20:50:09 Watusimoto repeat until we come to the end of the list
20:50:18 Watusimoto there will be some children remaining
20:50:41 Watusimoto go back to the top of the list and start again, looking for parents in the vectors
20:50:53 Watusimoto repeat until the child list is empty
20:51:23 Watusimoto pretty inefficient, but for 20-30 objects, it should be fine
20:51:56 Watusimoto though this is definitely an o(n^2) design
20:52:15 raptor hehe, yep
20:52:41 Watusimoto maybe an n^3
20:53:17 Watusimoto but the problem is you can't tell two items are releated unless they are immediately adjacent on the tree
20:53:33 Watusimoto that is, they have a parent-child relationship
20:53:41 raptor nested for loops all the way!
20:53:43 Watusimoto you look at parent-grandchild, and you'll see no connection
20:53:56 Watusimoto it's for loops, all the way down :-0
20:55:38 IAmBeard nest for loops all the way across the sky!  nested for loops, oh my god, nested for loops!
21:01:54 Watusimoto of course, we could go back to a centralized registration process
21:02:08 raptor ugh
21:02:12 Watusimoto that would solve everything!
21:02:22 Watusimoto except for the centralization issue
21:06:37 raptor well...  at least i learned lots about templates
21:09:33 Watusimoto we aer severely limited by the restrictions that each class only knows what it's parent is, and the classes can be registered in any order
21:10:32 BFLogBot - Commit b4ed0e9657c3 | Author: watusim...@bitfighter.org | Log: Fix error handling functions
21:10:34 Watusimoto we could, perhaps, add something to the macro to let a class interrogate its parent
21:11:08 Watusimoto which could in turn interrogate its parent; that would make ordering things much easier
21:12:49 Watusimoto though not easy to return a class in c++
21:15:31 Watusimoto or maybe a different approach
21:16:01 Watusimoto maybe we just stick everything in an unordered vector
21:16:04 Watusimoto as we do now
21:16:26 Watusimoto register all the base classes first, as we do now
21:16:34 Watusimoto then start with the child list
21:16:59 Watusimoto if we've registered a class' parent, we register the child, discard it
21:17:06 Watusimoto if we haven't, we come back later
21:17:15 Watusimoto keep iterating over the list until its empty
21:17:27 raptor that's what i thought you were already doing...
21:17:49 Watusimoto actually... this is pretty much the same as my other idea, but with simpler logistics (i.e. no mutliple vectors)
21:18:24 Watusimoto you mean currently?
21:18:49 raptor i mean what you're implementing right now
21:18:54 Watusimoto no
21:19:03 Watusimoto currently we register all base classes
21:19:09 Watusimoto then register children in arbitrary order
21:19:21 Watusimoto I'm proposing only registering children when the parent is registered
21:19:36 Watusimoto and iterating over the list a couple of times
21:19:55 Watusimoto so if a child is registered before its parent
21:20:08 Watusimoto sorry, if a child is preregistered before its parent
21:20:30 Watusimoto when registering the children, we hit the child, see its parent hasn't been registered, and move on to the next child
21:20:33 sam686 has joined
21:20:33 ChanServ sets mode +v sam686
21:20:36 Watusimoto then come back and check again
21:20:41 Watusimoto and again
21:20:49 Watusimoto and again, until we can register it
21:20:57 Watusimoto brb
21:31:25 Watusimoto ok, it's 11:30
21:31:28 Watusimoto i give myself until 12:00 to make this work
21:31:33 raptor ok
21:31:35 Watusimoto otherwise it's hast la vista
21:31:44 raptor ok, send me your work if not completed
21:38:33 Watusimoto as long as it doesn'
21:38:35 Watusimoto t suck
21:49:01 raptor well, if you hate it, i'll pick up again tonight
22:02:18 raptor ok, your time is up
22:03:48 Watusimoto it is
22:04:20 Watusimoto http://pastie.org/3968445
22:04:48 raptor ok
22:04:49 Watusimoto added static std::vector<const char *> extendedClasses;
22:04:55 Watusimoto this is the list of classes extended to date
22:05:14 Watusimoto now when you register a base class, it gets added to this list
22:05:36 Watusimoto    LuaW_Registrar1Arg()
22:05:36 Watusimoto    {
22:05:36 Watusimoto       registerClass<T>();
22:05:36 Watusimoto       getExtendedClasses().push_back(LuaWrapper<T>::classname);
22:05:36 Watusimoto    }
22:05:55 Watusimoto and when you extend, the class gets added to list
22:06:12 Watusimoto   template<class T, class U>
22:06:12 Watusimoto    void static extendClass(lua_State *L)
22:06:12 Watusimoto    {
22:06:12 Watusimoto       getExtendedClasses().push_back(LuaWrapper<T>::classname);
22:06:12 Watusimoto       luaW_extend<T, U>(L);
22:06:13 Watusimoto    }
22:06:29 Watusimoto so, you need to verify this actually works (have stubborn link error here)
22:06:49 Watusimoto then in registerClasses(L):
22:06:51 Watusimoto / Extend those that need extending... but in order  <=== iterate over this list extending ones with parents already in
22:06:51 Watusimoto       // getExtendedClasses() list.  Probabbly need check to see if you make a complete pass without adding any, it means
22:06:51 Watusimoto       // that the inheritance chain is broken, and it indicates an assertable error state. (otherwise, will loop forever)
22:06:51 Watusimoto       for(unsigned int i = 0; i < getExtensionFunctions().size(); i++)
22:06:51 Watusimoto          getExtensionFunctions()[i](L);
22:06:58 raptor one quick question, what is the exact relationship between the extended list and non-extended?
22:07:01 Watusimoto do what the commeens say
22:07:12 Watusimoto extended list?
22:08:47 raptor  getExtendedClasses()
22:08:52 Watusimoto ah
22:09:05 raptor getRegistrationFunctions()
22:09:11 raptor wait you renamed those
22:09:29 Watusimoto getExtendedClasses just gets a list of strings of the names of already-extended classes
22:09:39 Watusimoto anything with a parent on this list is safe to extend
22:09:46 raptor ah ok
22:09:52 raptor what i meant was
22:10:00 raptor before your current work
22:10:02 Watusimoto get RegistrationFns() is just a list of classes to be registered in any order
22:10:13 raptor when everything is registered arbitrarily
22:10:28 Watusimoto there are two steps to registering
22:10:31 Watusimoto 1. register
22:10:34 Watusimoto 2. extend
22:10:39 raptor explaint he extend part for me
22:10:48 Watusimoto resistration can happen in any order
22:10:56 raptor ok
22:10:59 Watusimoto extension is where you say a is a child of b
22:11:12 Watusimoto and I *thought* this could happen in any order, but it can't
22:11:18 Watusimoto b needs to be extended before a
22:11:25 Watusimoto and both need to be registered
22:11:34 raptor so all my work with  getRegistrationFunctions() was for naught
22:11:39 raptor i needed to use getExtensionFunctions() instead
22:11:50 Watusimoto I suppose it was
22:11:53 raptor ha!
22:11:55 Watusimoto but the logic would have worked
22:12:01 raptor ok, good, i'm glad you expained that
22:12:05 Watusimoto but the whole idea was flawed
22:12:32 Watusimoto so the macros either add a class to the registration list or
22:12:41 Watusimoto add it to both the registration and extension lists
22:12:48 Watusimoto everythign gets registered
22:12:54 raptor the registration list can be in any order?
22:12:54 Watusimoto only things with parents get extended
22:12:59 Watusimoto reistration can be in any order
22:13:04 raptor ok
22:13:10 Watusimoto at least that's what I think currently
22:13:12 raptor then I know better what needs done
22:13:12 Watusimoto :-)
22:13:14 raptor ha!
22:13:39 Watusimoto if you verify that names are added to the list properly, and then do that parent checking during extension iteration, it should work
22:14:07 Watusimoto but I'm not sure how to get the extension and parent classnames in order to check the list
22:14:18 Watusimoto you may need to register things as pairs
22:14:26 Watusimoto name, function
22:14:28 Watusimoto or soemthing
22:14:31 Watusimoto you'll figure it out
22:14:38 raptor yes, that is what i already implemented...
22:14:38 Watusimoto or I'll do it on Friday
22:14:42 raptor ok
22:14:45 Watusimoto yes
22:14:46 raptor i'll take another stab at it
22:14:55 Watusimoto ok, well see y'all in a week or so!
22:15:05 raptor later!
22:15:07 raptor and good ngiht
22:59:21 Watusimoto Quit (Ping timeout: 256 seconds)
23:14:42 Little_Apple has joined
23:14:51 Little_Apple helloooo
23:15:00 raptor hi
23:15:05 Little_Apple sup
23:16:06 raptor hi
23:17:55 Little_Apple working?
23:18:27 raptor yes
23:18:36 Little_Apple I SHALL LEAVE YOU IN PEACE
23:18:40 Little_Apple Quit (Client Quit)
23:49:57 raptor Quit ()
Index Search ←Prev date Next date→
These logs were automatically created by BFLogBot on irc.freenode.net.