User:Enus Linden/Office Hours/2009 January 09

[9:29] Saijanai Kuhn: ENus wants ot talk a bit about the object model for pyogp. I'd like to see it be a direct implementation of the scripting model I've been proposing, at least as far as the user interactions go
[9:31] Morgaine Dinova: 'Morning Enus!
[9:31] Morgaine Dinova: And a Happy New Year :-)
[9:31] Enus Linden: waves to the slowly rezzing crew
[9:31] Enus Linden: happy to you too morgaine!
[9:32] Enus Linden: how's it starting for ya?
[9:32] Morgaine Dinova: Well. I now have two 24" 1920x1200 LCDs in front of me :-)
[9:32] Enus Linden: oolala
[9:32] Enus Linden: can i sit next to ya? :P
[9:33] Enus Linden: hey sai
[9:33] Enus Linden: hi squirrel
[9:33] Morgaine Dinova: No, you can't. The candy in your mouth is too fattening, even as a proximity effect.
[9:34] Enus Linden: we can go jogging afterward :P
[9:34] Morgaine Dinova: chuckles
[9:34] Morgaine Dinova: Hope Sai's present today, rather than afk as usual
[9:35] Morgaine Dinova: Hiya JayR!
[9:35] JayR Cela: hi everyone
[9:35] Enus Linden: as soon as firefox stops acting like an ass i'll get a link to point to as a seed for pyogp object model talk if sai still wants to head that way today
[9:35] Morgaine Dinova: Oh, that sounds interesting
[9:36] JayR Cela: dont pick on Sai
[9:36] Enus Linden: is new tertitory for me tbh, sketching out what could become
[9:36] JayR Cela: he the one holding this whole inter-op thing together
[9:37] Enus Linden: no one is picking on sai
[9:37] Enus Linden: we adore him
[9:37] Morgaine Dinova: We love Sai
[9:37] Saijanai Kuhn: feels the love
[9:37] Morgaine Dinova: Woohoo! We love Sai even more when he's present :-)))
[9:37] Enus Linden: crap, i haven't sent the early draft.
[9:37] JayR Cela: this new RC works great
[9:37] Enus Linden: i'll send it and then get the link :)
[9:38] Enus Linden: gimme a sec
[9:38] Saijanai Kuhn: when I get my comp aback, will try to become productive asap. Bought a lcd tv that actually fits on the desk so arguing with roomate/significant other about proper use of TV set in my bedroom instead of living room
[9:38] JayR Cela: i have not tried building yet
[9:41] JayR Cela: well anyways seem to work pretty good for me
[9:41] Enus Linden: jayr, what does?
[9:41] JayR Cela: the new RC
[9:41] Enus Linden: is working pretty good for me so far as well :)
[9:41] JayR Cela: i aint tried building yet
[9:42] Enus Linden: alrighty, a link to a simple sketch of what pyogp could in time look like: https://lists.secondlife.com/pipermail/pyogp/2009-January/000217.html
[9:42] JayR Cela: but things seem to rezz faster
[9:42] Morgaine Dinova: Textual "sketch", hehe
[9:42] Enus Linden: ascii art lol
[9:42] JayR Cela: ya know this is an issue i want to bring up
[9:43] JayR Cela: older computers
[9:43] Morgaine Dinova: They should be banned ;P
[9:43] JayR Cela: i know buying a new computer is getting cheaper
[9:44] Morgaine Dinova: I was kidding of course. Even mobiles are becoming clients, so working on cut-down hardware is essential.
[9:44] JayR Cela: but i can barley afforf to keep food on the table
[9:44] Enus Linden: so what about older computers then jayr?
[9:45] JayR Cela: SL is a great place to meet people
[9:45] Morgaine Dinova: Enus: that list, is it a list of *PyOGP* objects as stated, or OGP objects?
[9:45] JayR Cela: please dont kill it by raiseing the entry level
[9:46] Enus Linden: pyogp morgaine
[9:46] JayR Cela: i been with Cathy for over 2 years
[9:46] Enus Linden: jayr, we've consistently done our best to not eleiminate support for hardware we've previously supported. LL will continue with that goal
[9:47] Morgaine Dinova: JayR: the solution to that problem is not to keep the requirements of SL depressed. The solution is to allow features to be selectable, and caps and OGP are intended to provide exactly that.
[9:47] JayR Cela: 3 years
[9:47] JayR Cela: we should highlight that
[9:47] Saijanai Kuhn: I think there's a case for pyogp objects to reflect the future direction of the OGP as far as what gets factored into what. WE're flexible and can chage of course, but it could make our job and the OGP team's easier if they see a one to one correspondence with their direction and our internal design
[9:47] Enus Linden: and morgaine nails it. new features should be optional
[9:48] JayR Cela: peop;e that ate actually in love wirh one in other
[9:48] JayR Cela: i know i am
[9:48] Saijanai Kuhn: is using a non-supported comp right now. fps 1.8 with all graphics at minium
[9:48] Enus Linden: sai: until OGP has something more, an OM will focus on the current OGP arch changes (agent domain and a few caps so far), plus compatibility with the current architecture
[9:48] Saijanai Kuhn: right.
[9:49] Enus Linden: essentially, thoughts were as follows as i put this (minimal) list together:
[9:49] Morgaine Dinova: Enus: I think I may have asked the wrong question then. Is that list supposed to reflect PyOGP's OO design (as a program), or is it intended to reflect the VW objects that PyOGP will handle?
[9:49] Saijanai Kuhn: guess I'm justing thinking of future directions...
[9:49] JayR Cela: well i love Cathy
[9:49] Saijanai Kuhn: Morgaine, for us, I think its both
[9:49] Enus Linden: Morgaine, i tended to map them 1 - 1
[9:50] Enus Linden: it's not complete at all, or even right, but I want to seed the discussion with something
[9:50] Saijanai Kuhn: will making user scripting model eaiser for sure
[9:50] Saijanai Kuhn: and the day to day QA should mostly be concerned with user-level tests I would think
[9:51] Enus Linden: essentially, the pyogp OO design would consist of very little I think. an agent, a region (and later region domain), and an agent domain (in the OGP context)
[9:51] Morgaine Dinova: Enus: not quite --- PyOGP will have tons of client-side objects that don't come down across the wire. Eg. it will have its own internal event system, being a client, and those events will not be the same thing as the incoming events from SL that will be mapped onto it.
[9:52] JayR Cela: look this may not be a very popular thing to discuss.........
[9:52] JayR Cela: but we are real people
[9:52] Morgaine Dinova: Enus: that was in answer to your !;! mapping
[9:52] Morgaine Dinova: 1:1
[9:52] Enus Linden: true morgaine
[9:52] JayR Cela: and i love my wife
[9:53] Enus Linden: and that is absent from the textual sketch :)
[9:53] JayR Cela: so do you want to talk about it or not
[9:53] Morgaine Dinova: JayR --- all you need to say is that you want features to be optional. I think we're working towards that.
[9:54] JayR Cela: peoples feelings are real
[9:54] Enus Linden: jayr: LL has your best interest in mind :) of course our goal will be to support older computers for all long as possible. modular components will help that wuite a bit
[9:54] Enus Linden: of course they are
[9:55] Morgaine Dinova: When features are optional then old machines can cope. There's a "simple" technical solution to those social problems, and supporting simple clients is on the work stack.
[9:55] Enus Linden: and the metaverse wants to support as much accessibility as possible, no matter the platform
[9:55] Morgaine Dinova: Yeah
[9:55] Morgaine Dinova: Enus: very good point, re accessibility
[9:56] Saijanai Kuhn: Which is why pyogp is importahnt, IMHO. If it runs in python, it should run on just about any hardware, even if ported to a different language
[9:56] Morgaine Dinova: Enus: that said, we've never had much success in trying to get Zero to focus on switching features off. For example, I've been promoting the idea of client control of the sim interest list, to provide for better sim and viewer scalability. But I'm not really having any success.
[9:57] Saijanai Kuhn: well, that's such a tough server-side issue Morgaine. I can see why he would want to sidestep it while we're staill getting TM, group IM and inventory workign
[9:57] Saijanai Kuhn: TP*
[9:58] Morgaine Dinova: Tough problems are the only ones worth working on :-)))))
[9:58] Saijanai Kuhn: yeah, but if you have to solve the simple problems first, you might as well work on those first anyway
[9:58] Morgaine Dinova: Aye, manpower problem there.
[9:59] JayR Cela: oh i vote Sai as the person of the month
[9:59] Enus Linden: i second
[9:59] Enus Linden: resources are pinched, that's true
[9:59] JayR Cela: yep
[9:59] Enus Linden: lots to do, more that we want to do collectively
[9:59] JayR Cela: see ya all later
[9:59] Saijanai Kuhn: later JayR have a good weekend
[10:00] Morgaine Dinova: Well I'd "third" ... except for the fact that Sai's not able to actually do those things since he's not a Linden :-) [but should be, hehe]
[10:00] Enus Linden: i suppose roi, cost, all play into decision making
[10:00] Saijanai Kuhn: my tendency to have brain feezes during interviews explains that last part, MOrgaine :-(
[10:00] Morgaine Dinova: Enus: I'm going to pretend I never heard you say "ROI, cost" :-))))
[10:01] Enus Linden: they are real unfortunately
[10:01] Enus Linden: that's the business side of things
[10:01] Enus Linden: the side i wish no one has to think about
[10:02] Enus Linden: so morgaine, what sorts of things would you want to see in this design proposal?
[10:02] Morgaine Dinova: They are very real ... but should not be used as an excuse for not moving tech forward. In general, tech can overcome ROI+cost issues, so using those issues to stop dev ideas is back to front. Often, not always :-)
[10:02] Enus Linden: like i said, it's new to me. i can hack and hack and never have to think about such a thing
[10:02] Enus Linden: but having a shared and vetted goal is useful sometimes
[10:03] Morgaine Dinova: Well my immediate comment is: where's the event system?
[10:03] Enus Linden: this is an open source effort after all. where i am the only contrib atm, still....
[10:03] Morgaine Dinova: "Event" as in app internals, not social :P
[10:03] Enus Linden: absent, and only initially considered atm
[10:04] Enus Linden: i looked back at Tao's zca based proposal a while back
[10:04] Morgaine Dinova: KK. Well I always *start* with the event system, and everything else is draped around it.
[10:04] Enus Linden: and will likely consider using that as a base model to infulence what we come up with
[10:04] Enus Linden: why is that morgaine?
[10:05] Morgaine Dinova: Because that way you can deal with concurrency without having to paddle into the dragon-infested waters of threading. Also, events map perfectly only pretty much everything, and people are very used to callback programming now, so it's "acceptable".
[10:06] Morgaine Dinova: So it's both a pragmatic and a powerful approach.
[10:06] Enus Linden: righto
[10:06] Enus Linden: was happy to have had a good first experience with eventlet running the UDP pipe
[10:07] Saijanai Kuhn: well, if our event handler is the funnel through which all events, including GUI callbacks get handled, and we can get it workign with eventlet, then we should have a pretty flexible/speedy system
[10:07] Enus Linden: Morgaine, do you have any examples of a core of a model like this?
[10:07] Morgaine Dinova: Did my research in concurrency and parallelism, so I know which dragons to fear --- don't go down the threading route. Even Intels latest TBB is a total disaster in that area.
[10:07] Enus Linden: like i said, new territory for me, who is no true dev, rather a qa-er with a taste for writing words that make computers do things
[10:08] Saijanai Kuhn: is self taught past 3 semesters of Cobol and the like
[10:08] Enus Linden: yeah, threading sucks, especially in python.
[10:08] Enus Linden: the first prototypes ran the event queue and udp processing in separate threads
[10:08] Morgaine Dinova: Enus: most game clients are structured that way. Pretty much any SDL application.
[10:08] Saijanai Kuhn: learned cobol from a studen of Admiral Hopper
[10:08] Enus Linden: but how to pass data around sucks in threading
[10:08] Morgaine Dinova: Hehehe, good ol' Gracie
[10:08] Saijanai Kuhn: They've made a stab at doing it with the SL client, but it was never formalized
[10:09] Enus Linden: eventlet allows for concurrent processing within a single thread, at least at the parent thread level anyway (not sure of the guts of greenlet etc yet)
[10:09] Saijanai Kuhn: so you've got 2-3 models at work in the SL client which aren't really compatible with each other
[10:10] Saijanai Kuhn: ENus, think that greenlet somehow maps corroutiens onto native threads or a pool of them
[10:10] Morgaine Dinova: I'm on the Imprudence team, so will be getting to grips with the event structure in the viewer. My initial view (largely without evidence) is that LL ahve done a reasonable job in the event system, because otherwise machines running viewers wouldn't be running at a mere 40% CPU. That's promising.
[10:10] Saijanai Kuhn: guess we should ask DOnovan to explain it at some point
[10:11] Enus Linden: or read the source sai :)
[10:11] Saijanai Kuhn: yea,m but I'm not as adventuresome as you whippersnappers
[10:11] Morgaine Dinova: Aye, eventlet provides co-routines from what I can gather. Not used them, but I've used coroutines a lot in other languages, most recently in Lua.
[10:11] Enus Linden: morgaine, any inclination to share what such a system could ideally look like?
[10:12] Enus Linden: i like the callback notion
[10:12] Enus Linden: muchly
[10:12] Morgaine Dinova: Enus: <chuckle> I've never had the problem of trying to keep things to myself :-))))
[10:12] Enus Linden: am familiar with it to some degree
[10:12] Saijanai Kuhn: I think that I've seen a 3D games programming book that discusses how to do this (may even have it) .
[10:13] Saijanai Kuhn: Callbacks are fragile I think
[10:13] Saijanai Kuhn: unless you have them registered with a central mechanism
[10:13] Morgaine Dinova: That's the idea, you register your callbacks with the event system
[10:14] Saijanai Kuhn: right, the dictionary of liasts of callback handlers I was talkign about
[10:14] Enus Linden: this was tao's zca based solution: https://lists.secondlife.com/pipermail/pyogp/2008-October/000205.html
[10:14] KirstenLee Cinquetti: must go, have a good evening/day/night everyone
[10:14] Saijanai Kuhn: trivial to implement a simple version in python. NOt sure about security issues and thee like given its python
[10:15] Enus Linden: the branch is still around, and i was leaning toward testing it out soon (in a non zca fashion naturally)
[10:15] Enus Linden: bye k
[10:15] Morgaine Dinova: Think of it as a funnel or hopper, with events falling in the top and a task allocator grabbing events from the bottom and farming out work. If you can structure your system in a way that *ALL* work comes into the hopper as events, then your app structure becomes a very clean event processing loop, and all actions can in principle be concurrent.
[10:16] Enus Linden: i don't see why we couldn't funnel that way
[10:16] Saijanai Kuhn: That was my intent from the beginning.
[10:17] Enus Linden: UDP = 1 funnel, event queue is s second (then the agent domain eq a third)
[10:17] Saijanai Kuhn: The Avatar_OBj is the reference that a script or GUI refers to. you can have a list of avatar objects and worith with list[i} or list[current]
[10:17] Saijanai Kuhn: and the callback handler tracks which avatar_obj applies
[10:17] Morgaine Dinova: Eg. I tend to even have frame drawing done that way: just pick your desired frame rate, set up a timer to inject redraw events into the system event queue, and dispatch to a redraw event handler when such an event pops out the queue. Then you don't even need a mainloop for your graphics.
[10:18] Saijanai Kuhn: in fact, SL client sorta does that, but in an obscure sort of way (at least to me)
[10:18] Enus Linden: what sorts of things would be an event in the pyogp client context?
[10:19] Enus Linden: packet received, eq call response?
[10:19] Saijanai Kuhn: well, user events (GUI commands/core macros), incomdding and outgoing packet messages
[10:19] Morgaine Dinova: It's early days for me in figuring out the SL client, but that's what I'll be doing this year, more than focussing on AWG.
[10:19] Saijanai Kuhn: and bunches of itnermediate stuff as needed
[10:19] Saijanai Kuhn: pafcket handlers and meta handlers
[10:20] Morgaine Dinova: Every I/O occurence should be an app event, for starters.
[10:20] Morgaine Dinova: Yeah
[10:21] Saijanai Kuhn: with PYthon it will tend to be a tad slow, but we don't need a rendering pipeline at this poitn, and we could conceivably redo the event handler in C/C++ and make it a native module for a graphical client
[10:21] Morgaine Dinova: Another way of thinking about it (kinda master principle for this) is that an app should consume zero CPU when there are no events, because it's simply blocked on the event queue.
[10:21] Saijanai Kuhn: aside from GUI monitoring of course
[10:22] Morgaine Dinova: No no, by definition nothing is happening in the GUI, since there are no events.
[10:22] Morgaine Dinova: A person clicking on something causes an event.
[10:22] Enus Linden: is it best t place events into a queue, or handle them one by one directly?
[10:22] Saijanai Kuhn: OK, but there's still low level events going on at the OS level to check for user actions
[10:23] Enus Linden: queues are likely good i reckon
[10:23] Saijanai Kuhn: queues make threading easier I believe
[10:23] Morgaine Dinova: Always queue, because that gives you async operation, and it allows tasks to spawn multiple subactions to be done later, and it allows for queues with priorities.
[10:23] Morgaine Dinova: Yeah
[10:25] Morgaine Dinova: Sure, the O/S is always using the CPU, but it's monitoring for events while running its idle task, and so we see it as "zero CPU" from a user perspective.
[10:25] Saijanai Kuhn: the wx model I used for the logger text box was to print to a file-like textbox which either appended directly to the wx textbox, or scheduled the event in a queue for later processing
[10:25] Saijanai Kuhn: depending on if the wx main thread was active or not
[10:25] Saijanai Kuhn: its how they implement their default debu window
[10:27] Morgaine Dinova: SDL uses threads too, but mostly it's for complete subsystems like audio because it's hard to factor those into callbacks and retain realtime behaviour. And the timers run in a separate thread too, but that's noddy.
[10:27] Enus Linden: morgaine: is there an implementation somewhere you know of i could reference for study (other than the sl viewer)? :D
[10:27] Saijanai Kuhn: me checks for that game book, might be sections online
[10:28] Enus Linden: pyov leverages libomv fot this
[10:28] Enus Linden: for*
[10:28] Morgaine Dinova: Enus: I can't think of a *specific* app I'd point to, but SDL in general is a very good reference for working with events, and there are tons of examples on the web. I probably have some good links on the fileserver, I'll fire some your way if I find. But really googling for SDL+events wil do it.
[10:29] Enus Linden: okies
[10:29] Morgaine Dinova: And they have good documentation, *lots* of it.
[10:30] Enus Linden: i see that
[10:30] Enus Linden: thanks
[10:31] Enus Linden: okies, i'll see about getting something together soonish (that being anywhere from 3 days to 5 weeks)
[10:31] Enus Linden: unless someone beats me to it
[10:31] Enus Linden: i gotta run to a meeting now
[10:31] Morgaine Dinova: Oh joy, my SDL links are borked. I hate it when sites reorganize, makes bootmarks pointless.
[10:32] Saijanai Kuhn: key, eus I can't do chat logs from this comp so if you can im me a transcript I can get it up on the wiki once I get my comp
[10:32] Morgaine Dinova: KK Enus, thanks for meeting :-)
[10:32] Morgaine Dinova: I'll send you notecard Sai
[10:32] Saijanai Kuhn: thanks MOrgaine
[10:32] Enus Linden: thanks for the chatting morgaine and sai
[10:33] Saijanai Kuhn: Readcing list: anything by or edited by Andre Lamouthe
[10:33] Enus Linden: look forward to learning and pulling something together
[10:33] Saijanai Kuhn: black art of computer game series
[10:33] Morgaine Dinova: Yeah, there's nothing like actual running code <chuckles>
[10:36] Morgaine Dinova: I have several game-programming texts ... I don't find them helpful though, they're either too general to be of use, or too specific to be of use in any system other than theirs.
[10:37] Morgaine Dinova: Making notecard
[10:37] Saijanai Kuhn: well lemotuthe liked to give a general overview and then develop a code library based on tthat oerview,.

User:Enus Linden/Office Hours/2009 January 09

Navigation menu

Search