#pentagram@irc.freenode.net logs for 13 Mar 2005 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage

[00:00:40] <-- megawatt has left IRC (Read error: 110 (Connection timed out))
[06:34:43] --> Colourless has joined #Pentagram
[06:34:43] --- ChanServ gives channel operator status to Colourless
[06:35:53] <Colourless> hi
[09:28:24] <wjp> hi :-)
[09:58:28] <Colourless> hi
[11:02:21] --> Fingolfin has joined #pentagram
[11:02:21] --- ChanServ gives channel operator status to Fingolfin
[14:16:16] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[17:26:01] <-- Fingolfin has left IRC ("42")
[18:47:25] --> watt has joined #pentagram
[18:48:05] <watt> hmm.. getting a l compile error on ShapeViewerGump for get_class_name
[18:48:47] <Colourless> what error?
[18:49:13] <watt> get_class_name undeclared
[18:49:35] <Colourless> hmm
[18:49:41] <Colourless> forgot to include a header most likely
[18:49:43] <wjp> missing include
[18:49:48] <wjp> I'll commit a fix
[18:49:51] <Colourless> #include "Usecode.h" at the top
[18:49:57] <Colourless> i do that a lot don't i :-)
[18:50:48] <watt> well, just about got something I can commit for memory pooling.
[18:50:48] <Colourless> should give a more useful error like use of undefined class Usecode
[18:51:23] <wjp> yeah, it probably should
[18:51:57] <wjp> fix committed, by the way
[18:52:54] <wjp> I guess UCProcess::dumpInfo should also output the classname
[18:53:51] <wjp> gah, I need more RAM... my system can't handle BilinearScaler.cpp :-)
[18:54:19] <Colourless> i actually considered splitting it into multiple files
[18:55:14] <Colourless> would probably actually end up being faster overall
[18:55:19] <Colourless> less data to sort through
[18:57:40] <watt> ouch.. seg fault.
[18:58:03] <wjp> interesting error message:
[18:58:10] <wjp> /tmp/cc9uLAzR.s:356112: Error: can't resolve `0' {.gnu.linkonce.t._ZN9Pentagram22BilinearScalerInternalIj16Manip_32_A888_GCjE13ScaleBilinearEP7TextureiiiiPhiiib section} - `.LCFI101' {.gnu.linkonce.t._ZN9Pentagram22BilinearScalerInternalIj16Manip_32_A888_GCjE13ScaleBilinearEP7TextureiiiiPhiiib section}
[18:59:38] <wjp> probably out of memory or out of diskspace or something...
[18:59:53] <wjp> compiling without optimizations goes significantly better :-)
[19:00:06] <Colourless> i'll split things up
[19:18:22] --> megawatt has joined #pentagram
[19:19:00] <megawatt> These disconnects are really getting on my nerves now.
[19:24:49] <megawatt> yikes.. the assertions that the pools are empty before destructing them is failing...
[19:27:33] <megawatt> thinking I'm getting rid of the memory manager before the processes get killed
[19:35:24] <-- watt has left IRC (Read error: 110 (Connection timed out))
[19:52:00] --> watt has joined #pentagram
[19:55:29] <-- megawatt has left IRC (Read error: 110 (Connection timed out))
[19:58:55] <Colourless> this just aint working...
[20:02:15] <Colourless> functions just wont instantiate
[20:05:56] <Colourless> need to think different then
[20:18:36] --> megawatt has joined #pentagram
[20:19:06] <-- watt has left IRC (Read error: 110 (Connection timed out))
[20:19:34] <megawatt> Kernel::~Kernel(): Assertion `processes.empty()' failed. I guess not
[20:19:38] <megawatt> I assume we want to fix that.
[20:20:24] <megawatt> arg... having to repost old messages that didn't send before.
[20:20:56] <megawatt> The kernel still seems to have processes when it destructs.
[20:21:27] <megawatt> Is adding a call to reset a good idea, or does that horribly break something
[20:21:37] <Colourless> yay no link errors
[20:27:34] <megawatt> hmm.. the Simple pool may not work well for Process. A number of them are around 4k in size
[20:27:55] <Colourless> usecode processes
[20:28:09] <Colourless> be the stack
[20:29:30] <Colourless> i would ignore processes for now, and focus on objects only
[20:29:43] <Colourless> IMO, usecode processes should have their own dedicated pool
[20:29:55] <megawatt> thats doable.
[20:29:55] <Colourless> they are very common, and use a fairly substantial amount of memory
[20:36:19] <megawatt> hmm.. let's say 4224 bytes nodes with 10 nodes at a time?
[20:37:14] <Colourless> committed bilinear scaler stuff
[20:37:18] <Colourless> hopefully it will work :-)
[20:37:39] <Colourless> or maybe not
[20:38:02] * Colourless shakes head at up to date error
[20:42:22] <Colourless> committed now
[20:46:11] <-- megawatt has left IRC (Read error: 60 (Operation timed out))
[20:56:35] --> megawatt has joined #pentagram
[20:56:46] <megawatt> there we go... the only other process that doesn't get pooled to my knownledge is 560 bytes and seems to last the entire game.... AvatarMoverProcess probably... I can live with that.
[20:59:01] <megawatt> still need to show the speed of the Allocators verses normal allocation.. probably a MemoryManager::testAllocators console command, and I need to write console command to get the stats of the allocators.
[20:59:29] <megawatt> but, I think this can be commited now
[20:59:32] <Colourless> depending how you store, i'm betting A LOT caster
[20:59:35] <Colourless> *faster
[21:00:41] <megawatt> I know the ReferenceAllocator is slower, but that's because it just uses malloc and free ant then stores the pointer in a set.
[21:00:54] <Colourless> why do that?
[21:01:43] <megawatt> it's simply the fallback allocator in memory manager. In case the proper allocator can't store the memory
[21:01:55] <megawatt> like that 560 byte process.
[21:01:58] <Colourless> why use a set?
[21:02:07] <Colourless> that's going to waste memory
[21:02:43] <megawatt> yes, I know... I just wanted more than one allocator for proof of concept
[21:03:00] <Colourless> well, i wouldn't use it in a release build
[21:03:11] <Colourless> seems like something unnecessary
[21:03:49] <megawatt> yeah.. I guess I should remove it before commiting
[21:11:02] <wjp> AvatarMoverProcess 560 bytes? hm, are you sure?
[21:12:08] <Colourless> doesn't really make sense...
[21:15:04] <megawatt> well, It might be another process or object.
[21:15:12] <megawatt> I'm just taking a guess
[21:29:46] <Colourless> so either process or object... and it's big...
[21:31:49] <Colourless> music proces
[21:31:50] <Colourless> s
[21:31:53] <Colourless> int song_branches[128];
[21:32:01] <Colourless> there is 512 bytes
[21:35:13] <megawatt> sounds right.
[21:35:30] <megawatt> anyway, commited the first version.
[21:35:44] <megawatt> Feel free to rip it to pieces :-)
[21:36:57] <Colourless> i think you have forgotten something
[21:37:06] <Colourless> *cough* forgot to add files
[21:39:35] * Colourless waits...
[21:42:41] <megawatt> oh.
[21:43:11] <Colourless> :-)
[21:46:03] <megawatt> you didn't need those, right? :-)
[21:46:18] <Colourless> i'm pretty sure i do
[21:48:37] <Colourless> msvc doesn't like this:
[21:48:37] <Colourless> freeNodes = new (SimplePoolNode*)[nodes_];
[21:49:00] <Colourless> you are not supposed to use () with new
[21:49:26] <Colourless> thinks you are doing a cast
[21:54:10] <Colourless> other than that it seems all fine
[21:55:30] <megawatt> probably not...
[21:56:01] <megawatt> wondering how I should do that line...
[21:56:14] <Colourless> wondering?
[21:56:25] <Colourless> freeNodes = new SimplePoolNode*[nodes_]; is fine
[21:56:35] <megawatt> is it?
[21:56:44] <Colourless> yes :-)
[21:56:47] <Colourless> committed change
[21:56:54] <megawatt> oh.. ok
[22:00:17] <Colourless> my only comment... the last free pointer becomes the next used... in theory this is not a problem (since our code is obviously perfect and we would never read an invalid pointer) but in making it so the last freed is not the next allocated might be a nice idea
[22:01:14] <Colourless> obviously there is no 'easy' way of doing this with the way you current have things
[22:01:30] <Colourless> but it's not something that i am concerned enough with to actually bother doing anything to change
[22:01:57] <Colourless> anyway, i've got to go
[22:01:59] <Colourless> later
[22:02:03] <-- Colourless has left IRC ("casts improved invisibility")
[22:18:10] <-- megawatt has left IRC (Read error: 110 (Connection timed out))
[22:18:19] --> megawatt has joined #pentagram
[22:33:25] --> Kirben has joined #pentagram
[22:33:25] --- ChanServ gives channel operator status to Kirben