[03:46:57] MikePaixao has joined #peragro-dev
[03:46:57] ChanServ sets mode: +o MikePaixao
[03:47:39] MikePaixao has parted:
[07:52:33] thebolt|zzz changed nick to: thebolt
[12:34:40] sueastside has joined #peragro-dev
[12:34:40] ChanServ sets mode: +o sueastside
[14:19:42] |sueasts| has joined #peragro-dev
[14:21:51] ChanServ sets mode: +o sueastside
[16:23:31] caedes has joined #peragro-dev
[16:23:31] ChanServ sets mode: +v caedes
[19:01:48] |sueasts| has joined #peragro-dev
[19:29:53] ChanServ sets mode: +o sueastside
[19:57:22] caedes has quit: "nightmare reset by peer"
[20:35:25] caedes has joined #peragro-dev
[20:35:26] ChanServ sets mode: +v caedes
[20:46:42] caedes has quit: Read error: 60 (Operation timed out)
[20:57:50] caedes has joined #peragro-dev
[20:57:50] ChanServ sets mode: +v caedes
[21:02:17] iceeey has joined #peragro-dev
[21:02:17] ChanServ sets mode: +o iceeey
[21:02:34] <thebolt> hey iceeey , up for some talking today?
[21:02:41] <iceeey> sure
[21:04:29] <thebolt> a bit about plans etc..
[21:04:48] <thebolt> good, now +15? (so i can finish up some stuff first and be concentrated ;)
[21:04:57] <iceeey> that's fine
[21:13:44] <iceeey> i don't mind a normal thebolt, but concentrated thebolt might be a little too strong ;)
[21:22:55] <JohnTitor> SVN--> thebolt commited r566 to peragro_src with log message: - Marten did a "half-time" commit of first Stackless Python integration. (+11115, -160).
[21:23:22] <sueastside> 11k is that all you? nice!
[21:23:28] <iceeey> if those are not auto-generated, :)
[21:23:52] <sueastside> heh
[21:23:52] <thebolt> well, they contain some msvc files
[21:24:21] <thebolt> but a majority is hand written.. although it doesn't do too much yet
[21:24:32] <thebolt> so.. what i would like to discuss is _the plan_ ;)
[21:24:56] <sueastside> sounds evil :P
[21:25:37] <iceeey> and if that's just half a commit :)
[21:25:44] <thebolt> what i'm going to work on now is a system where other modules can basically call CreateTasklet("mypythonfile.py", "blahmethod")
[21:25:47] <thebolt> and then schedule those
[21:25:49] <thebolt> (in c++ that is)
[21:26:04] <iceeey> okay
[21:26:18] <thebolt> second thing would be to get the pool-of-microthreads and pool-of-realthreads stuff to work
[21:26:33] <thebolt> so that one can write stuff which actually takes longer than very-short in a good way
[21:26:50] <iceeey> those are separate things, correct?
[21:26:50] <thebolt> but then the question is a bit how we want to procede..
[21:26:52] <thebolt> yes
[21:27:01] <iceeey> so you only have one microthread at a time now
[21:27:16] <thebolt> well, you only have one _executing_ microthread at a time ;)
[21:27:23] <iceeey> that's what i meant
[21:27:40] <thebolt> which means you don't have to handle any concurrency issues in the microthreads themselves
[21:28:26] <iceeey> can you explain how you see this working? this microthread stuff ends up confusing me
[21:28:52] <thebolt> sure
[21:29:10] <thebolt> okay, the plan is for it to be mainly single threaded
[21:29:22] <thebolt> mostly to keep us sane and be able to keep a development timeline within bounds
[21:29:36] <iceeey> and you are talking about real threads
[21:29:40] <thebolt> yes
[21:29:43] <thebolt> OS level threads
[21:29:52] <thebolt> stuff that can execute on different cores etc
[21:29:57] <iceeey> right
[21:30:04] <iceeey> worry about multiple real threads later
[21:30:17] <thebolt> well, they do have a part in the whole, but i can get to that later..
[21:30:35] <thebolt> so, in a single threaded app you have a mainly linear flow
[21:30:51] <thebolt> which is okay, but in games you have many things which are more like "continious methods over long time"
[21:31:33] <thebolt> now, some games do this by having a "tick" method on all objects and a finite state machine (more or less) in each
[21:31:41] <thebolt> for example HL and HL2 is that way
[21:32:12] <thebolt> so every frame/update all object get their tick methods called, they do what they want, set a new state and return
[21:33:05] <thebolt> but, in principle what you want is coroutines.. methods which can be resumed "in the middle" which is where stackless python and its microthreads comes in
[21:34:02] <thebolt> so instead of "setting state" and returning, the microthread does what it wants, if it wants to do more things it yields ("is nice") and continues on when it gets control back
[21:34:12] <thebolt> and when it is finished it might execute another script or just return and be finished
[21:35:12] <thebolt> now, execution of such tasklets could both be global such as "update" methods for AI
[21:35:36] <thebolt> or "update environment with data from erosion simulation"
[21:36:22] <thebolt> or more localized, response to an event "player clicked" triggered by events
[21:36:43] <thebolt> the first kind would more or less be infinite loops while second are more of short runners
[21:38:25] <thebolt> so what i have started to write now is code to setup python, allow creation of tasklets from python callables, ways for a tasklet to say "ok, i am finished, let someone else execute" as well as "okay, i am finished, wake me up again in M seconds"
[21:39:10] <thebolt> now, for many of these "short run and then finished" tasklets the overhead of creating a new tasklet can be non-ignorable
[21:39:34] <thebolt> so the idea (taken from stackless archives;) is to have a pool of pre-created tasklets that execute the functions in them
[21:39:42] <thebolt> with me so far? ;)
[21:39:47] <iceeey> yes
[21:40:22] <thebolt> good :)
[21:40:38] <thebolt> so that is basically the execution core stuff.. now there is one complication though
[21:40:43] <iceeey> i was mostly familiar with the stuff before pooling, but i wanted to make sure i was on the same page
[21:41:10] <thebolt> tasklets are cooperative, so they should yield in pretty short time not to "lock up" the system
[21:41:23] <thebolt> there is a simple system in place to catch any tasklet using too many cycles and kill it
[21:41:47] <thebolt> however sometimes you have operations that needs long time to run, cannot easily be interupted halfway / you want it to run etc..
[21:41:55] <thebolt> and you want it to wake up a specific tasklet when done
[21:42:43] <thebolt> one such could be db, another network.. so there we need a way of running stuff in a separate OS thread, have a threadsafe queue as interface and then a tasklet running in the main thread to communicate with that thread
[21:44:59] <iceeey> so the db and network are in C++?
[21:45:23] <thebolt> well, we can put the barrier wherever we want
[21:45:29] <thebolt> but i think there are parts we want to do in c++ ;)
[21:45:46] <thebolt> and those are two i can think of as examples of that..
[21:45:52] <iceeey> well, since we won't have division of tasklets into OS level threads for a while
[21:46:11] <thebolt> if ever
[21:46:16] <iceeey> yes
[21:46:18] <thebolt> we won't have that until python is multithreaded
[21:46:36] <thebolt> however, they could be written in python and use python threads (also os-threads)
[21:46:44] <thebolt> but the problem is still the same
[21:46:53] <thebolt> you need a tasklet-aware interface to communicate with them
[21:47:47] <thebolt> all this of course is given you agree to the general direction ;)
[21:48:25] <iceeey> i think it will take some getting used to developing in the new paradigm
[21:49:32] <iceeey> but supposedly it will lend itself to a more natural implementation
[21:49:47] <thebolt> yes, it is a bit unconventional i guess.. and yea, it is based on what eve have used stackless for (although they do more than i intend now at least in python)
[21:51:47] <iceeey> i guess the only way to know is to try it :)
[21:57:30] <iceeey> perhaps more telling will be some discussion of how each game system would be implemented--in C++ or as stackless tasklet? what API does it expose?
[21:58:43] <thebolt> hm, yea
[21:58:54] <thebolt> and who does it;)
[22:00:32] <iceeey> we're going to end up making assumptions and abstractions about each system, it's best to come up with them sooner than later :)
[22:00:37] <thebolt> Yep
[22:01:39] <iceeey> unfortunately, the wiki is a mess
[22:03:22] <iceeey> since it is a new branch, new wiki?
[22:03:45] <thebolt> hm, not sure wiki is best to keep track of such things.. hm..
[22:04:01] <iceeey> could use SVN
[22:04:08] <iceeey> but what, text files?
[22:04:51] caedes has quit: "nightmare reset by peer"
[22:06:05] <thebolt> hm.. w8
[22:15:17] <sueastside> thebolt: you forgot to commit something? libptcore.vcproj?
[22:16:06] <thebolt> ah, sorry
[22:16:24] <thebolt> btw, compiling it is a bit.. tricky ;)
[22:16:37] <sueastside> a bit? :)
[22:16:45] <thebolt> well, short guide
[22:16:48] <JohnTitor> SVN--> thebolt commited r567 to peragro_src with log message: - Marten added missing file. (+233, -0).
[22:17:04] <thebolt> 1. Get stackless python.. including headers (matching!) and libraries
[22:17:06] <thebolt> 2. compile boost
[22:17:14] <thebolt> boost::python, link it against stackless
[22:17:17] <thebolt> 3. compile pt ;)
[22:17:35] <sueastside> boost has to be compiled?
[22:17:51] <thebolt> boost::python (and a few other subcomponents) have
[22:21:32] <thebolt> iceeey: okay, no better idea than wiki really.. :/
[22:43:14] <sueastside> thebolt: what line did you use for bjam? seems it just copies headers :/
[22:43:32] <iceeey> there's some option for python iirc
[22:44:50] <thebolt> hm.. lets see
[22:45:32] <thebolt> bjam -sTOOLS=vc-8_0 --with-python-version=2.5 --with-python-root=e:\src\stackless-2.5 stage
[22:53:16] <thebolt> when i get a bit furthuer i'll compile it for vc8 at least and provide it ;)
[22:53:47] <sueastside> ok now it seems to compile, ty :)
[23:05:30] <sueastside> hmm failed 120 skipped 160 that cant be good...
[23:23:31] <sueastside> there we go, needed some extra paths...
[23:25:28] <thebolt> yea.. it might need some hand tweaking still :/
[23:25:38] <iceeey> so back to the plan...
[23:26:18] <thebolt> yea
[23:26:27] <sueastside> yes the plan, making customizable characters, where you can change their length!
[23:27:34] <iceeey> like variable-length Unicode ;)
[23:28:58] <thebolt> well, one thing that should be decided pretty soon is the development strategy :)
[23:29:14] <thebolt> top down / bottom up, design+build big blocks or small iterations ?
[23:31:13] <iceeey> a little of both :)
[23:33:40] <thebolt> :)
[23:33:53] <thebolt> well, my point was more like, as soon as we can run something in python/c++ combination
[23:34:02] <thebolt> should we start buidling something that can create an entity
[23:34:09] <thebolt> then add on the something to load it etc
[23:34:18] <thebolt> or should we first write a solid db component, and then use it ;)
[23:35:10] <iceeey> I think we've been shooting for bottom up with our design
[23:35:43] <sueastside> hmm what could be causing this? http://rafb.net/p/yIfR7V27.html
[23:35:53] <iceeey> or at least it is more inspiring :)
[23:35:55] <thebolt> yea.. one problem with that is the long times before you can test anything "for real"
[23:36:22] <thebolt> sueastside: ahm.. let me try to remember, think i got that too
[23:36:34] <thebolt> i think it is that it includes wrong pyconfig or so
[23:36:41] <thebolt> and STACKLESS doesn't get defined..
[23:40:16] <iceeey> well let's see, who is going to actively code this? at present it's you and I
[23:41:21] <thebolt> hm, maybe you and i have different definition of "top down" and "bottom up" it seems...
[23:42:39] <sueastside> if you can remember what you did to fix, please let me know...
[23:42:47] <thebolt> sueastside: i am trying..
[23:43:08] <thebolt> sueastside: you don't have include-files from "non-stackless" python in your include dir?
[23:45:34] <iceeey> thebolt, well top down is designing the major components and then linking them together, bottom up is adding on small parts, linking together as you go
[23:45:46] <thebolt> iceeey: not really the usual definition of it ;)
[23:46:19] <thebolt> or well, that is one way to see it rather
[23:46:30] <thebolt> but yea, we agree on what to do at least
[23:47:15] <thebolt> something towards the agile type.. short cycles, write small parts and integrate those
[23:47:20] <iceeey> right
[23:47:59] iceeey has quit: "Leaving"
[23:48:09] iceeey has joined #peragro-dev
[23:48:09] ChanServ sets mode: +o iceeey
[23:48:31] <thebolt> and try to get something "game-like" up and running as soon as we can ;)
[23:48:31] <iceeey> my bad
[23:48:44] <iceeey> yeah
[23:48:56] <sueastside> thebolt: got it!
[23:49:21] <iceeey> however you have to consider the big picture or it'll end up a big patchwork :)
[23:49:34] <sueastside> it was taking the wrong pyconfig.h ...