User:Which Linden/Office Hours/2010 Feb 11

• [11:07] Sebastean Steamweaver: And he appears!
• [11:07] Morgaine Dinova: Hiya Which :-)
• [11:07] Sebastean Steamweaver: wonders if Which detected the plant fertlizer.
• [11:07] Sahkolihaa Contepomi: o_o
• [11:08] Sebastean Steamweaver: Which will be so happy when we get avatar transparency.
• [11:08] Questar Utu: Wouldn't plant fetilizer be sort of like cat nip is to cats?
• [11:08] Which Linden: hiya
• [11:08] Sebastean Steamweaver: I would guess so, yes.
• [11:08] JB Hancroft: hi
• [11:08] Which Linden: yeah I will Sebastean!
• [11:10] JB Hancroft: Which, you're looking very "green"
• [11:10] Which Linden: that's right, let it not be said that this isn't a green-friendly company
• [11:10] Sebastean Steamweaver: chuckles.
• [11:11] JB Hancroft: nor... that content matters ;)
• [11:11] JB Hancroft: *context* :)
• [11:12] Which Linden: ah...sorry, I'm a bit distracted today
• [11:12] Sebastean Steamweaver: No worries Which.
• [11:12] JB Hancroft: What's the distraction?
• [11:13] Which Linden: we're moving our development stations to a different colo, so I'm scrambling to get to a good new host and copy all my files over
• [11:13] Sebastean Steamweaver: Well, thanks for showing up today all the same :) We appreciate the time.
• [11:14] Which Linden: faster development!
• [11:14] Which Linden: man, I love moore's law
• [11:14] Sebastean Steamweaver: Hehe
• [11:14] JB Hancroft: Are you physically moving people, also?
• [11:14] Which Linden: no
• [11:14] Which Linden: well, maybe, depends on how much you're offering me to.... :-P
• [11:15] JB Hancroft: Moore's law is great, if you are buying machines, in the future. It bites you when you buy one, though...
• [11:15] Sebastean Steamweaver: Hehe
• [11:15] Sahkolihaa Contepomi: I...don't recall seeing this OH before: [11:15
• [11:15] Which Linden: yeah moore's law is like deflation
• [11:15] Sahkolihaa Contepomi: Yoz Linden?
• [11:15] Which Linden: oh that's cool; yoz is awesome
• [11:15] JB Hancroft: What's a Yoz?
• [11:16] Which Linden: yoz is unique
• [11:16] Melchizedek Blauvelt: Started last week Sah, it'sabout AU etc
• [11:16] JB Hancroft: That would be Unique Linden
• [11:16] Sahkolihaa Contepomi: Ah. I skipped most of last weeks OHs due to college work.
• [11:16] Sebastean Steamweaver: Which, are you familiar at all with dealing with in-world assets?
• [11:17] JB Hancroft: Which - I'm curious about what LL is doing about virtualization... for sims?
• [11:17] Which Linden: JB: well, it's a complex project
• [11:17] Which Linden: I feel that if we were to do that it might just be easier to virtualize the entire OS
• [11:18] Which Linden: Sebastean: not sure what you mean by "dealing with"
• [11:18] Sebastean Steamweaver: IT's more in line with Andrew's hours, I'll admit, but I just had a quick question about raycasting. If that's outside your line of work, that's fine.
• [11:19] Sebastean Steamweaver: i.e. having a script define a raycast offset, and finding the key of the first object that intersects with it, if any.
• [11:19] JB Hancroft: Sebastean - would you use a phantom temp object and check collisions?
• [11:19] Which Linden: Ah! Definitely not my speed, I'm afraid
• [11:20] Sebastean Steamweaver: No problem Which :)
• [11:20] Sebastean Steamweaver: JB - I'd like to avoid using a temp object if at all possible.
• [11:20] Which Linden: I'm more of a web services/UI guy
• [11:20] JB Hancroft: Which... http-in fall into your area?
• [11:21] Which Linden: JB: that's a bit closer, I know some people
• [11:21] JB Hancroft: How has the deployment of http-in affected the traffic in/out of SL, with the Web? Is it as you'd expected?
• [11:22] Which Linden: "There's this guy I met in prison, he knows a lot of people who do http-in jobs."
• [11:22] JB Hancroft: eek!
• [11:22] Melchizedek Blauvelt: lol
• [11:22] Sebastean Steamweaver: lol
• [11:22] JB Hancroft: I look terrible in stripes... :(
• [11:22] Which Linden: That's a great question, and I don't know the answer to it. I believe that http-in hasn't changed our traffic dramatically.
• [11:23] Which Linden: uptake has been slow
• [11:23] Which Linden: Which was expected
• [11:23] Which Linden: At previous office hours, people have complained about how the interface is inconvenient enough that they
• [11:23] JB Hancroft: we're using http-in for Relay For Life this year
• [11:23] Sebastean Steamweaver: There are a lot of systems I intend to implement HTTP-IN on, but sometimes it's a matter of time to switch it over from the old email systems.
• [11:23] Which Linden: would prefer to use the old email or xml-rpc, even though those are busted in various ways
• [11:24] Which Linden: Yeah, it's totally a matter of the devil you know
• [11:24] Which Linden: Also, it's difficult to update scripts
• [11:24] JB Hancroft: we did a scaleability test... rezzed 1800 kiosks in a sim, and they all were able to handle traffic very quickly... nice
• [11:25] Sebastean Steamweaver: I think http_in is the best thing since sliced bread. But sometimes if you don't have something completely ready, you're more inclined to use a working existing system.
• [11:25] Which Linden: Nice
• [11:25] Which Linden: JB: that's actually awesome, you should, like, give seminars on that
• [11:25] Sebastean Steamweaver: I will admit that I'd like the limits for http_in to be more like llEmail as far as character counts.
• [11:27] JB Hancroft: ZenMondo Wormser did the baseline coding of http-in ... did a nice job.
• [11:28] Which Linden: size of bodies limited to 2k bytes....that is pretty small
• [11:28] Which Linden: that's like a packet!
• [11:29] JB Hancroft: being able to say what offset you wanted to retrieve, or a "get more/next" callback would be nice...
• [11:30] Sebastean Steamweaver: I was hoping at some point they might consider expanding that a bit. It can be a bit of a hassle to separate data over to messages, instead of sending things "all at once." There are a few cases I've encountered where I've had to do that.
• [11:31] Which Linden: yeah; it seems like a good design practice to start off with low limits to avoid crushing everything, but to slowly raise the limits as usage dictates
• [11:31] JB Hancroft: I've had to rely on some off-world parsing, to pull out the pieces/parts I want in-world
• [11:34] Which Linden: to some degree, that's desired; I believe part of the point was the recognition that inworld scripts are never going to be as powerful as externally-hosted scripts
• [11:34] Sebastean Steamweaver: That may change with Babbage's "Big Scripts" project.
• [11:35] JB Hancroft: so much for my plans to sell Apache WebServer prims :(
• [11:35] Which Linden: yeah, maybe; in which case maybe the limit would be raised for big scripts
• [11:36] Which Linden: how would you feel about trading off the 64 queued requests for larger body sizes? I.e. 4k body sizes but only 32 of them queued at a time?
• [11:36] Which Linden: (just hypotehtically)
• [11:36] Sebastean Steamweaver: Well personally, I don't use nearly 32 as it is.
• [11:36] Sebastean Steamweaver: I guess it depends on the traffic one uses.
• [11:36] Which Linden: I guess it would be hard to tell how much of that you use
• [11:36] Which Linden: Or is there a way to directly inspect the number of queued requests?
• [11:36] JB Hancroft: is there a way to know?
• [11:37] Sebastean Steamweaver: Hmm
• [11:37] Sebastean Steamweaver: Good point, Iwas just going by requests recieved in X period of time.
• [11:37] JB Hancroft: And that gives an average, not peak values.
• [11:37] Jonathan Yap: Maybe it could be user-settable; I had a need for more queued requests for a project but all very small packet-wise
• [11:38] JB Hancroft: "I've never dropped a packet.... that I know of" - UDP
• [11:39] Which Linden: You could time your request handler to see how long it takes to process one request, then use that to determine an rps rate for handling, and if you see yourself at that rate for N requests, you can make some assumptions about how many of those N requests were buffered
• [11:40] JB Hancroft: that's a good idea... I like it :)
• [11:40] Sebastean Steamweaver: Doesn't llEmail have a wya to get queued emails? Haven't looked at email functions in a while.
• [11:40] JB Hancroft: I think you just get an indicator if there is "more"
• [11:41] Sebastean Steamweaver: email(string time, string address, string subj, string message, integer num_left)
• [11:41] Sebastean Steamweaver: The last one gives the number of emails left.
• [11:41] Which Linden: hm that's nice
• [11:41] JB Hancroft: cool...
• [11:41] Jonathan Yap: You use llGetNextEmail on a timer event to pick up messages
• [11:42] Sebastean Steamweaver: Maybe since versioning is coming out, a similar parameter could be added to http_in
• [11:44] Which Linden: Maybe!
• [11:44] Sebastean Steamweaver: releases a cricket in Which's pot.
• [11:45] Which Linden: I just put that bug in the ear of some developers
• [11:45] Sebastean Steamweaver: Hehe, awesome :)
• [11:45] Saijanai Kuhn: g'day all
• [11:45] Sebastean Steamweaver: Hey there Saij
• [11:46] Which Linden: Hi Sai!
• [11:46] Which Linden: long time no see
• [11:46] Saijanai Kuhn: been a strange past few months
• [11:46] JB Hancroft: Hi Sai :)
• [11:46] Saijanai Kuhn: BUT, one happy thing: just got my squeak to squeak shared memory IPC working with OpenGL
• [11:46] Morgaine Dinova: waves at Sai
• [11:47] Morgaine Dinova: Cool Sai!
• [11:47] Which Linden: your squake?
• [11:47] Morgaine Dinova: What was the solution?
• [11:47] Which Linden: squeak
• [11:47] Saijanai Kuhn: so I can draw using OpenGL, copy to a shared memory buffer, and read it in the next instance
• [11:47] Saijanai Kuhn: solution was me using wrong variables in opengl call, as expected
• [11:48] Sebastean Steamweaver: The solution was using wrong variables, or was that the problem?
• [11:48] JB Hancroft: picky, picky ;)
• [11:48] Saijanai Kuhn: I WAS using the wrong parameters
• [11:48] Sebastean Steamweaver: Ahh
• [11:48] Sebastean Steamweaver: Well you never know JB, sometimes you can get things to work using "wrong" things ;)
• [11:48] Saijanai Kuhn: next milestone: share buffer with SL plugin and draw from squeak to SL plugin texture
• [11:49] Sebastean Steamweaver: *cough*PosJump*cough*
• [11:49] JB Hancroft: nods... I found a bug the other day... the code "appeared" to be working, and it was too bugs interacting, to cause "correctness" :(
• [11:49] Morgaine Dinova: SysV shared memory?
• [11:50] Saijanai Kuhn: more or less. FreeBSD shared memory
• [11:50] Saijanai Kuhn: whichis what the plugin uses for Mac OS X IIRC
• [11:50] Saijanai Kuhn: shmget shmat etc
• [11:51] Which Linden: What's the end goal, Sai? squeak runtime for writing sl viewer plugins?
• [11:51] Saijanai Kuhn: yeah, basically. The ultimate version would be croquet on a prim
• [11:52] Saijanai Kuhn: so could have telepresence between cobalt and SL
• [11:53] Which Linden: That's hella ambitous, man
• [11:53] Saijanai Kuhn: this also solves an issue they've had with cobalt where they couldn't easily use VNC with cobalt because it was drawing opengl to the screen, which VNC normally won't pick up
• [11:54] Saijanai Kuhn: but I THINK its possible to tell VNC to use a buffer instead
• [11:54] Which Linden: hey guys;unrelated; if someone makes a JIRA for inspecting the amount of pending http-in requests, I'll link it to https://jira.secondlife.com/browse/MISC-3077
• [11:54] [[User:JIRA-helper: [#MISC-3077|JIRA-helper: [#MISC-3077]]:
• [11:54] Saijanai Kuhn: so I sorta solved a Cobalt project problem at the same time
• [11:54] Sebastean Steamweaver: I'll do that now Which :)
• [11:54] Saijanai Kuhn: double brownie points
• [11:54] Sebastean Steamweaver: opens a JIRA pag.
• [11:55] Which Linden: thanks Sebastean
• [11:56] Which Linden: Sai: this cobalt? [1]
• [11:57] Saijanai Kuhn: correct. Croquet Hax and Tapple Gao in Groupies are part of that project
• [11:58] Saijanai Kuhn: so hopefully Julian will stop being quite so condenscending when I'm in the team meetings on skype :-)
• [11:59] Saijanai Kuhn: but I'm happy. Been hitting my head against this wall for a very long time
• [11:59] Saijanai Kuhn: feels so goooood
• [11:59] JB Hancroft: I'm glad you got it figured out, Sai.
• [11:59] JB Hancroft: What did you do to discover the problem?
• [12:00] Saijanai Kuhn: asked in the squeak-dev mailing list
• [12:00] JB Hancroft: nice
• [12:00] Saijanai Kuhn: I had parameter issues is all (which is what I expected)
• [12:00] Saijanai Kuhn: OpenGL newb
• [12:01] Which Linden: Everyone's an OpenGL newb at heart
• [12:01] JB Hancroft: I was at a conference not long ago where they had "Human Search Engine" sessions. You would stand up to the microphone, ask your question, and those who knew how to contribute to the answer would meet you aside.
• [12:01] Saijanai Kuhn: well, once I understand the squeak FFI a little better
• [12:01] Sebastean Steamweaver: [2]
• [12:01] [[User:JIRA-helper: [#SVC-5372|JIRA-helper: [#SVC-5372]]:
• [12:02] Saijanai Kuhn: I won't be so newb. You can use most opengl calls in squeak the same way you can any other smalltalk. So I can play with opengl interactively, mod something and do it again
• [12:02] Saijanai Kuhn: that's a main reason for writing the SL plugin tester in squeak.
• [12:03] Sebastean Steamweaver: (Does that seem like an accurate description of t he proposal?)
• [12:03] Which Linden: Linking, Sebastean
• [12:04] Which Linden: OK I should run! Thanks all for a great discussion
• [12:05] Which Linden: I may not be here next week due to Pycon
• [12:05] JB Hancroft: thanks, Which
• [12:05] Sebastean Steamweaver: Thanks for the office hours which :)
• [12:05] Which Linden: Haven't checked the schedule yet
• [12:05] JB Hancroft: Good luck with all the "moving"
• [12:05] Which Linden: Heh thanks! I'm firing up my rsync now
• [12:05] Sahkolihaa Contepomi: See you Which.
• [12:05] Which Linden: Take care
• [12:05] Saijanai Kuhn: take care which