[00:05:03] --> Kirben has joined #pentagram
[00:05:03] --- ChanServ gives channel operator status to Kirben
[00:16:11] <-- wjp has left IRC ("Zzzz...")
[01:08:22] --> Coren_ has joined #pentagram
[01:08:42] <-- Coren_ has left #pentagram ()
[01:08:48] --> Coren_ has joined #pentagram
[01:08:59] * Coren_ waves.
[02:25:56] --> Dark-Star has joined #pentagram
[03:42:32] <-- Dark-Star has left #pentagram ()
[05:46:42] * Coren_ is away: sleep
[06:09:48] --> Colourless has joined #Pentagram
[06:09:48] --- ChanServ gives channel operator status to Colourless
[06:11:20] <Colourless> wjp: dynamic_cast = bad. Should use a different method to get the UCProcess from a Process, such as virtual UCProcess * getUCProcess();
[07:23:35] <Colourless> later
[07:23:39] <-- Colourless has left IRC ("casts invisibility")
[09:30:27] <-- Darke has left IRC (capek.freenode.net irc.freenode.net)
[09:36:40] --> Darke has joined #pentagram
[09:36:41] <-- Darke has left IRC (capek.freenode.net irc.freenode.net)
[09:36:43] --> Darke has joined #pentagram
[12:12:01] --> De4thClaW has joined #pentagram
[12:12:08] <-- De4thClaW has left #pentagram ()
[14:03:08] --> wjp has joined #pentagram
[14:03:08] --- ChanServ gives channel operator status to wjp
[14:15:14] --> Colourless has joined #Pentagram
[14:15:19] --- ChanServ gives channel operator status to Colourless
[14:16:44] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[14:34:28] --> Dark-Star has joined #pentagram
[15:25:38] <-- Colourless has left IRC ("restarting, brb")
[15:25:38] --> Ember has joined #pentagram
[15:26:45] --> Colourless has joined #Pentagram
[15:26:51] --- ChanServ gives channel operator status to Colourless
[15:29:05] <-- Darke has left IRC (Killed (NickServ (Ghost: Ember!~Darke@m008-254.nv.iinet.net.au)))
[15:29:09] --- Ember is now known as Darke
[15:32:56] --- Colourless is now known as Colourlessy
[15:33:20] --- Colourlessy is now known as Colourless
[15:34:51] <wjp> hm, did you ever figure anything out about what data needs to be copied to a new 'spawn inline' process?
[15:35:53] <Colourless> well, they can't take args, so i think only the this pointer is required
[15:38:32] * wjp nods; ok, that was my current guess
[15:40:32] <wjp> the this pointer was at BP+06, right?
[15:40:37] <Colourless> yes
[15:41:08] * Darke nods.
[15:41:26] <Colourless> there also the possibility that spawn inlines don't have an object associated with them, hence the reason the this pointer isn't pushed
[15:43:19] <wjp> in the inlined code at PYROS::26E9 BP+06 is used
[15:43:31] <Colourless> ok
[15:46:59] <wjp> hm, maybe it wouldn't be a bad idea to actually test some of this new code :-)
[15:47:19] * wjp looks around for some semi-simple code using spawn/implies
[15:49:20] * Coren_ is back
[15:49:43] <Colourless> i don't think there is any simple code involving spawn
[15:54:41] <Darke> Depends what you're looking for. Class 38 is relatively simple and has an implies.
[15:54:53] <Darke> Hrm. That's calli though.
[15:55:11] <wjp> I could create a DummyProcess and have calli spawn that
[15:55:22] <wjp> (a process that just waits n ticks)
[16:01:16] <wjp> hm, 38:80h is just a basic 'look', it seems
[16:11:14] <wjp> ugh, it "segfaults" now because the this pointer passed to 38:80 is 0 :-)
[16:11:34] * Darke will let you two spawn and imply things as he wanders off to sleep. *wink* Night!
[16:11:39] <Colourless> :-)
[16:11:40] * Darke snorks.
[16:11:44] <wjp> night :-)
[16:11:54] <Colourless> cya
[16:11:54] * Coren_ wavies to Darke.
[16:12:08] <Darke> Though generally it's *my* job to imply things. Though spawning is someone else's... err... work. *gigglewink*
[16:12:21] --- Darke is now known as DarkeZzz
[16:12:21] * wjp ignores accesses to segment 0 for now
[16:12:38] * wjp ooohs! it works!
[16:13:00] <Coren_> "Oooo! Colors!"
[16:13:27] <wjp> it actually waits for 4 cycles while my DummyProcess is.. umm.. dummying :-)
[16:13:48] <Colourless> wjp: i've been thinking that usecode pointer access should be in a specific function
[16:14:00] <wjp> yeah, it should
[16:14:03] <Coren_> The u8 usecode-equivalent uses processes? Coolness.
[16:14:17] <Colourless> u8 is multithreaded
[17:27:53] <-- Coren_ has left IRC (Excess Flood)
[17:27:59] --> Coren_ has joined #pentagram
[20:29:09] --- Dark-Star is now known as Dark-Star|afk
[20:39:28] <-- Colourless has left IRC ("casts invisibility")
[22:07:48] <-- DarkeZzz has left IRC (Read error: 113 (No route to host))
[22:41:58] --- Dark-Star|afk is now known as Dark-Star
[23:39:01] <wjp> <Colourless> wjp: dynamic_cast = bad. Should use a different method to get the UCProcess from a Process, such as virtual UCProcess * getUCProcess();
[23:39:17] <wjp> why? isn't that what dynamic_cast/RTTI is for?
[23:41:29] <wjp> I really don't like the idea of having to add getUCProcess(), getPhysicsProcess(), getAIProcess()... functions to Process
[23:49:15] <Coren_> That /is/ what dynamic_cast<>() is for.
[23:49:45] <wjp> pity Colourless isn't here to elaborate on his statement
[23:51:17] <Coren_> His statement is confusing; dynamic_cast<>() does exactly the equivalent of a virtual function call like he describes.
[23:52:56] <wjp> any idea if there are compilers for some platforms (handhelds or something) that don't support dynamic_cast properly?
[23:53:07] <wjp> (like some have issues with exceptions)
[23:53:09] * Coren_ ponders.
[23:53:54] <Coren_> It is not impossible that MSVC breaks this.
[23:54:28] <Coren_> But then again; breaking a program to controt to MS's idea of the C++ language is Evil. :-)
[23:55:40] <wjp> for exceptions the problem is some pda compilers, btw