User:Hidenori Glushenko/Sandbox

From Second Life Wiki
Jump to navigation Jump to search

Transcript of Linden's office hours:

[8:01] Babbage Linden: hi nick

[8:01] Babbage Linden: hi becky

[8:01] Nock Forager: Hi Babbaage

[8:01] Babbage Linden: nock, sorry

[8:01] Nock Forager: NP, everybody misspelled at first. :)

[8:02] Babbage Linden: thanks for coming

[8:02] Nock Forager: hmm, acctually I'm not a good scripter. Here to listen some update infor about Mono...

[8:03] Babbage Linden: that's fine

[8:03] Nock Forager: Bugs differences bitween LSL2 and Mono.

[8:03] Babbage Linden: i'll wait a few minutes for people to turn up, then give an overview of where we are

[8:04] Fake Fitzgerald: hi

[8:04] Babbage Linden: hi fake

[8:04] Nock Forager: lol everybody fall

[8:04] Becky Pippen: wheeee

[8:04] Babbage Linden: it's possible to make it across if you're lucky

[8:04] Fake Fitzgerald: I didn't fall

[8:05] Babbage Linden: hi miya

[8:05] Creem Pye: thanks

[8:05] Miya Watanabe: hello

[8:05] Creem Pye: howdy

[8:06] Babbage Linden: hi creem

[8:06] Nock Forager: Hi

[8:06] Fake Fitzgerald: hi

[8:06] Babbage Linden: let's give people a couple more minutes, then i'll start

[8:06] Babbage Linden: i'll ping the Mono groups too

[8:08] Babbage Linden: so, here's where we are with 1.24

[8:09] Babbage Linden: we had some problems initially with a debug server build, which was causing problems with 1.24.1

[8:09] Babbage Linden: then 1.24.2 fixed a number of crash bugs with features other than mono

[8:09] Babbage Linden: and 1.24.3

[8:10] Babbage Linden: after looking at the crash bugs, the next priority was issues that affect both LSL and Mono scripts

[8:10] Babbage Linden: as these affect existing content

[8:11] Babbage Linden: 1.24.4 which we're rolling out now fixed a problem with LSL script scheduling that was causing state_exit events to run slowly

[8:11] Babbage Linden: as well as state changes

[8:11] Babbage Linden: with scripting running on the original scripting engine

[8:11] Creem Pye: ah, so there will no longer be a 22ms delay for state changes?

[8:11] Babbage Linden: as well as in some cases the order of timer events vs state_exit and state_entry events

[8:11] Babbage Linden: correct creem

[8:12] Babbage Linden: what was happening in 1.24.1-3 is that scripts were yielding when a state change was pending

[8:12] Babbage Linden: so, you could only do 1 state change per time slice and so per frame

[8:13] Babbage Linden: also, because scripts were yielding all the time when state changes were pending, that slowed down state entry a lot

[8:13] Babbage Linden: as a sim running at 45 hz has a frame time of 22ms, that made it look like state changes were taking longer

[8:13] Babbage Linden: they weren't, they were just being gated by the frame rate

[8:13] Creem Pye nods

[8:14] Babbage Linden: also, the event ordering was changing as previously state_exit and state_entry events were being run immediately

[8:14] Babbage Linden: in 1.23 and before

[8:14] Babbage Linden: when the script was yielding on state change pending, it gave a timer event the chance to sneak in before the state_entry/exit event

[8:15] Babbage Linden: 1.24.4 also fixes a problem with llEmail

[8:15] Babbage Linden: that caused email to not be delivered to a script under some circumstances

[8:16] Babbage Linden: and fixed a problem with prepending to a list having side effects

[8:16] Babbage Linden: we're now moving on to looking at problems which only affect Mono scripts

[8:16] Creem Pye: will scripts need to be reset to take advantage of these fixes?

[8:17] Babbage Linden: we'd really like to be able to get a good repro for http://jira.secondlife.com/browse/SVC-2908

[8:17] Babbage Linden: which i think is actually a number of separate issues

[8:17] Babbage Linden: but we haven't been able to repro any of them yet

[8:18] Babbage Linden: we're currentlly looking at http://jira.secondlife.com/browse/SVC-2751

[8:18] Babbage Linden: which has a good repro

[8:18] Babbage Linden: and then will probably tackle the other Mono specific bugs in http://jira.secondlife.com/browse/SVC-1276

[8:18] Babbage Linden: if nothing else comes up in the meantime

[8:18] Babbage Linden: creem, no you don't need to reset scripts to see the fixes to the scheduler

[8:19] Babbage Linden: the changes are in the simulator code

[8:19] Babbage Linden: and will take effect on running scripts

[8:19] Creem Pye: hm the svc-2751 repro could use some llSleeop functions I think

[8:20] Creem Pye: sometimes chat arrives out of order, even within the same event

[8:20] Babbage Linden: yes, agreed

[8:20] Creem Pye: (but I guess if you had another object in the same sim listening, it should always receive messages in the correct order)

[8:20] Babbage Linden: moon metty tried it with llSleep(3) calls and still saw the problem

[8:21] Babbage Linden: and http://jira.secondlife.com/browse/SVC-2365 suggests there are other problems with scripts being reset

[8:21] Babbage Linden: so that's where we are now

[8:22] Babbage Linden: new crash bugs seem to have been fixed

[8:22] Babbage Linden: LSL2 is mostly working as it was

[8:22] Babbage Linden: and we're going to look at the Mono only issues next

[8:22] Babbage Linden: sound reasonable?

[8:22] Creem Pye: sure

[8:23] Creem Pye: I have a question - will the state change fixes in 1.24 affect the execution speed of on_rez at all?

[8:23] Creem Pye: oops 1.24.4

[8:23] Babbage Linden: no

[8:23] Becky Pippen: sounds like you've accomplished a lot of fixes already! Those reset issues are nasty.... hope they are easy to find and fix.

[8:23] Babbage Linden: are you seeing rez behave more slowly for scripts running on the original scripting engine creem?

[8:24] Babbage Linden: (Mono scripts rez more slowly as they do more work)

[8:24] Creem Pye: yeah, running slightly more slowly (~1 frame), and also using up slightly more script time than LSL2

[8:25] Babbage Linden: hi zena

[8:25] Creem Pye: the application I was looking at was scripted bullets, and they "initialize" on rez to become enabled. And with their speed, the execution speed of on_rez affects the minimum range

[8:25] Zena Juran: hiyas everyone :-)

[8:25] Babbage Linden: the on_rez handler should run fine

[8:26] Creem Pye: I'm using llSetName() in that function, so maybe the UTF16 being used in Mon ois causing the slight slowdown

[8:26] Babbage Linden: but Mono has to check a digital signature when it first rezes an assembly which takes longer

[8:26] Creem Pye: er llSetObjectName

[8:26] Babbage Linden: but with bullets you are probably rezzing the same script repeatedly, so should only see that hit the first time

[8:26] Babbage Linden: Mono also has to do more set up of objects than LSL

[8:27] Creem Pye: ah I see

[8:27] Babbage Linden: so rezzing can take slightly longer

[8:27] Becky Pippen: are there any tricks to minimize that setup time?

[8:27] Babbage Linden: make sure you do as much script sharing as possible

[8:28] Babbage Linden: it minimises the time the simulator spends checking signatures

[8:28] Babbage Linden: and saves memory too

[8:28] Babbage Linden: so, if you have a display with lots of XYText scripts for example

[8:28] Babbage Linden: copy the same compiled script in to the object many times

[8:29] Babbage Linden: instead of using recompile scripts in selection

[8:29] Creem Pye: in terestsing

[8:29] Babbage Linden: which will create a new XYText assembly for each script

[8:29] Nock Forager: hmhm

[8:29] Babbage Linden: if everyone takes copies of the same script when they use popular scripts

[8:30] Babbage Linden: sharing will happen between objects too

[8:30] Babbage Linden wants to see only one XYText assembly per simulator

[8:30] Creem Pye: btw since it seems that scripts in an avatar's inventory remember if they were compiled as LSL2 or Mono, it might be nice to have a UI option in the script editor, when the script is in avatar inventory

[8:30] Creem Pye: (the same "Mono" checkbox, I guess)

[8:31] Babbage Linden: that's tricky, as the simulator populates the checkbox by examining the bytecode

[8:31] Babbage Linden: the dataserver doesn't know if a script in your inventory is mono or lsl

[8:32] Babbage Linden: we could extend the database to store that information

[8:32] Creem Pye: but the script in your inventory has its bytecode attached?

[8:32] Babbage Linden: but it would be considerably more work

[8:33] Babbage Linden: also, knowing whether nested objects contain mono scripts is even harder

[8:33] Babbage Linden: so showing a mono checkbox for objects is really hard

[8:33] Babbage Linden: you would have to recurse through the object checking the information for all scripts

[8:34] Becky Pippen: makes sense

[8:34] Babbage Linden: so, it would be nice to have

[8:34] Creem Pye: hm yeah, nested objects also often don't reflect the true permissions

[8:34] Babbage Linden: but a lot of work

[8:34] Babbage Linden: hi tegg

[8:34] Tegg Bode: Hi All

[8:35] Creem Pye: hello

[8:35] Babbage Linden: any other questions?

[8:35] Nock Forager: Hi Tegg, Imaze, Keimar

[8:35] Babbage Linden: how have peoples experiences with mono been?

[8:35] Babbage Linden: hi imaze

[8:35] Keimar Kuhn: Hi

[8:35] Imaze Rhiano: hi

[8:35] Creem Pye: very smooth sailing so far. my only annoyance was that batch-converting scripts would enable scripts that were disabled

[8:36] Babbage Linden: ah, interesting

[8:36] Babbage Linden: could you file that as a bug please?

[8:36] Creem Pye: sure

[8:36] Babbage Linden: if it's not already in jira

[8:36] Babbage Linden: i haven't seen that yet

[8:37] Creem Pye: sure thing

[8:37] Babbage Linden: hi gabriel

[8:37] Gabriel Linden: hiya

[8:37] Gabriel Linden: hows it going?

[8:38] Imaze Rhiano: there has been also some negetive noise about Mono in scripter groups

[8:38] Imaze Rhiano: saying that mono is crashing sim, consuming more processor time, etc...

[8:39] Babbage Linden: i'm not aware of any mono crash bugs at this point

[8:39] Babbage Linden: i'd be interested in seeing mono using more processor time too

[8:39] Gabriel Linden: yeah

[8:39] Babbage Linden: it may use slightly more when scripts are doing nothing

[8:39] Babbage Linden: as mono scripts check whether they need to migrate when they're run

[8:40] Imaze Rhiano: I tried to ask from them what they are talking about - but no one didn't provide list of crash bugs or examples

[8:40] Tegg Bode: I am getting a lot more crashing this week on both RC and 1.20, and not using mono scripts yet :)

[8:40] Babbage Linden: there have been problems with the web services this week

[8:40] Babbage Linden: that have caused concurrency drops

[8:40] Creem Pye: heavy text processing could be slower with mono, right?

[8:41] Babbage Linden: but we're seeing a pretty low crash rate with 1.24.4.95600

[8:41] Creem Pye: like llList2CSV(llCSV2List()) of something really long

[8:41] Gabriel Linden: so these might be coincidence, as many people are thinking about mono atm

[8:41] Babbage Linden: mono has to convert strings to utf-8 when passing them to library calls implemented in C++

[8:42] Babbage Linden: that could take longer

[8:42] Babbage Linden: which is the common case

[8:42] Babbage Linden: but in generally Marshalling data from Mono to C++ is very fast

[8:42] Imaze Rhiano: what about those reports about using more cpu time? could it be that all SIM monitor tools are not yet optimized for Mono?

[8:43] Babbage Linden: some of the library calls have been reimplemented in managed code and should run much faster there

[8:43] Babbage Linden: lists are now implemented as ArrayLists for Mono scripts

[8:43] Babbage Linden: so indexing in to them should be constant time instead of requiring a search

[8:43] Babbage Linden: for example

[8:44] Babbage Linden: i'd like to see examples where running Mono scripts use more time than LSL"

[8:44] Babbage Linden: i haven't seen any examples yet

[8:44] Gabriel Linden: its very unlikely you'd see a huge jump in cpu time imho

[8:44] Babbage Linden: just idle scripts using up slightly more time

[8:45] Creem Pye: maybe the performance hit adds up if there are thousands of idle scripts in a sim

[8:45] Christos Atlantis: does that idle time affect the sim, if there are alot of idle scripts , like in a furniture store that has poseballs in almost every piece

[8:45] Bartlee Arai: It would be nice if you had a suite where you could do compartive analysis of mono to lsl and track local maxima

[8:46] Babbage Linden: imaze, most of those are now fixed in 1.24.4

[8:46] Babbage Linden: see the mono meta issue in jira for the status

[8:46] Bartlee Arai: comparative*

[8:46] Imaze Rhiano: ok - that was list I received last night

[8:46] Imaze Rhiano: so - it was bit outdated info then

[8:46] Babbage Linden: creem, long term, idle scripts shouldn't consume any CPU time

[8:47] Jam Meili: do thousand idle scripts contribute then more to sim lag then before?

[8:47] Babbage Linden: they should be moved to a non-running scripts list

[8:47] Babbage Linden: and only become runnable when they have pending events

[8:47] Babbage Linden: we have plans to address that

[8:47] Babbage Linden: but it may not be for a while

[8:48] Babbage Linden: in the meantime, i doubt the extra work mono scripts do would have a noticable effect

[8:48] Babbage Linden: even with 1000s of them in a sim

[8:49] Christos Atlantis: I heard mono scripts taste like chicken

[8:49] Christos Atlantis: to many rumours

[8:49] Babbage Linden: yes, agreed

[8:50] Babbage Linden: mono was the biggest change in 1.24

[8:50] Nock Forager: yes, many rumours :)

[8:50] Christos Atlantis: most are saying we should not recomplie

[8:50] Babbage Linden: so is being cited as the cause of many things

[8:50] Bartlee Arai: How long before Mono is where you think it needs to be, ball park?

[8:50] Babbage Linden: but mostly, if you're not running mono scripts, your problem is unlikely to be mono

[8:50] Babbage Linden: and for most people, most of the time, mono scripts will work fine

[8:51] Bartlee Arai: the good old 90 10

[8:51] Jam Meili: why it seems mono affects also old scripts? is that mono-related or just bugs that happened in modified servercode?

[8:51] Christos Atlantis: one small thing I did notice, is that the speed of the scripts is a bit faster when running a swarm script, it made the pet move faster

[8:51] Gabriel Linden: we need good reproducable cases if issues are found, if everyone avoids recompilation we wont get them

[8:52] Babbage Linden: we left the original scripting engine alone as much as possible

[8:52] Babbage Linden: but we needed to make a few changes to allow mono to run alongside it

[8:52] Babbage Linden: the state change problems are a good example

[8:52] Babbage Linden: the old scripting engine interpretted 1 instruction at a time

[8:53] Babbage Linden: Mono executes small pieces of code at once

[8:53] Babbage Linden: so we had to change the script scheduling code to cope with both engines

[8:53] Christos Atlantis: one more dumb question, if I am the owner of a script and recompile it, will all others using my script have a there items recompiled also?

[8:53] Babbage Linden: and managed to subtly change script execution behaviour in the process

[8:54] Babbage Linden: christos, no

[8:54] Babbage Linden: only the copy you recompile

[8:54] Jam Meili: ok, so that "eps" in the statistics is referred to that pieces of code that run at once? or how should we interpret that?

[8:54] Babbage Linden: it's like saving a script to produce a new script

[8:54] Jam Meili: are that library calls in c# or something?

[8:54] Christos Atlantis: so we have to recompile every single script in our stores?

[8:54] Babbage Linden: other objects still reference the old bytecode asset and so don't change

[8:55] Babbage Linden: christos, if you want to create new versions of all of them yes

[8:55] Babbage Linden: if they share scripts, the better way is to recompile 1

[8:55] Babbage Linden: then copy the new scripts in to the others

[8:55] Babbage Linden: to get more bytecode sharing

[8:55] Babbage Linden: you'll also want to test all the objects to make sure they work after conversion too

[8:56] Christos Atlantis: I have 7000 pieces of furniture in 5 stores, that is a very big task

[8:56] Babbage Linden: christos, agreed

[8:56] Creem Pye: ko Babbage, I've created a Jira item for the batch script conversion bug: SVC-2987

[8:56] Babbage Linden: you need to decide whether converting the scripts inside makes sense

[8:56] Babbage Linden: thanks creem

[8:57] Babbage Linden: jam, the eps change was due to Mono running small pieces of code at once

[8:57] Babbage Linden: we have no way of counting instructions with Mono easily

[8:57] Christos Atlantis: ok, so if I do not convert, will the furniture ie (pose balls) stop working

[8:57] Jam Meili: each recompile creates a new c# assembly, so i guess it uses also more memory if we compile same scripts in each prims over and over, is that right?

[8:57] Babbage Linden: so, instead we count how many events the script it executing

[8:58] Babbage Linden: which can be compared between Mono scripts and scripts running on the original scripting engine (OSE from now on)

[8:58] Babbage Linden: christos, if you don't convert your scripts they will continue to run as before

[8:59] Christos Atlantis: ok, ty those where my main concerns, I can now make logical choices

[8:59] Babbage Linden: jam, if you keep compiling scripts over and over

[8:59] Babbage Linden: eventually Mono unloads them if they're not being referenced by a script

[9:00] Babbage Linden: so, you don't need to worry about that

[9:00] Babbage Linden: but, you should try to have as many objects reference each assembly as possible

[9:00] Babbage Linden: to minimise the numbers of assemblies that mono needs to keep around

[9:00] Jam Meili: hum i said it maybe wrong. i mean if i use the same script like in hudred prims and isntead of copying one compiled in all, if i would create a script in each and recompile the source, it would use like hundred times more memory?

[9:00] Babbage Linden: it doesn't know that scripts are the same just because they have the same source

[9:01] Babbage Linden: but if you drag compiled scripts in to objects, it knows that they are sharing

[9:01] Jam Meili: so we could tune our scripts in that way, what wasnt possible in the old engine?

[9:01] Babbage Linden: and only needs to keep 1 assembly in memory

[9:01] Creem Pye: it would be nice if the scripts had a checksum on the bytecode to check if they're identical

[9:01] Babbage Linden: the OSE didn't do any sharing

[9:01] Becky Pippen: Is OSE the new term for the LSL VM back end? It's the term that replaces awkward names like LS2VM, or LSL-LSO, or LSL2LSOVM... ?

[9:01] Babbage Linden: so, if you had 1000 bullets flying around

[9:01] Babbage Linden: each would use 16K

[9:02] Babbage Linden: with Mono, they might use 1K shared between them

[9:02] Babbage Linden: if all the guns contained copies of the same compiled script

[9:02] Christos Atlantis: will mono allow for you to implement use of other scripting and programing choices in SL?

[9:02] Creem Pye: creating the UUID of a script based on its sha-160 checksum would be nice =)

[9:02] Babbage Linden: christos, yest

[9:02] Christos Atlantis: :)

[9:02] Jam Meili: ok, thats great and hopefully will make combat sims and such to work better. is there another mono-related impriovement we could use to tune the usage of resources on a sim?

[9:02] Babbage Linden: it will allow us to enable other languages to script SL in the long term

[9:03] Babbage Linden: we have been careful to keep that option open while working on LSL on Mono

[9:03] Babbage Linden: but there is still more work to be done before we get there

[9:03] Christos Atlantis: well, my dream would be if I could see a game engine running inside SL

[9:04] Babbage Linden: jam, bytecode sharing is the big thing that you can do to help Mono work effeciently

[9:04] Christos Atlantis: that would make the possibilities endless, mini games inside SL like a WoW

[9:04] Babbage Linden: Christos, SL is like a game engine in many ways

[9:05] Babbage Linden: lots of game engines have scripting engines and physics engines like SL

[9:05] Babbage Linden: games like dark life have been WoW like games in SL for a long time

[9:05] Christos Atlantis: yes, but it lacks the tools to make a good platform for developing game play

[9:05] Creem Pye: one thing you'd need to do is give estate managers much more control over what avatars can do

[9:05] Babbage Linden: there are some missing features, agreed

[9:06] Creem Pye: like forbid external attachments, and maybe force an avatar to have a certain style of appearance

[9:06] Babbage Linden: and many people are building things other than games

[9:06] Babbage Linden: so, we need to be careful to keep the platform neutral

[9:06] Christos Atlantis: like being able to control movement of props in non linear routes

[9:06] Babbage Linden: and make extensions where they are most useful to the most people

[9:06] Imaze Rhiano: if you want game development for SL - then you need also better controls for texture usage and model/prim usage for SIM owners

[9:06] Creem Pye: yep

[9:07] Imaze Rhiano: but that is bit offtopic

[9:07] Babbage Linden: we want to enable the widest array of applications possible in SL

[9:07] Babbage Linden: but we have limited resources

[9:07] Babbage Linden: so have to be smart about prioritizing improvements

[9:07] Creem Pye: megasims would be a nice start :D

[9:08] Creem Pye is a vehicle creator

[9:08] Christos Atlantis: I think the number 1 with residents is stability, so I will agree with you, you need to keep it stable for a long period and understand it before adding more features

[9:09] Babbage Linden: and most of the effort at linden is working on stability

[9:09] Jam Meili: hehe megasims would require changes in alot of parts of the server- and viewercode as also to expect owners would use server resources wisely, i guess we should not expect that any time soon, it's not very realistically right now

[9:09] Babbage Linden: which is why the scripting improvements are relatively slow in coming

[9:09] Christos Atlantis: and scaleability is also something I would think will help

[9:09] Babbage Linden: Mono was mostly me working on my own until near the end of the project

[9:09] Christos Atlantis: wow

[9:09] Christos Atlantis: great job!

[9:09] Bartlee Arai: Nice

[9:09] Nock Forager: yup!

[9:09] Babbage Linden: help! i'm being beaten with a car

[9:09] Creem Pye: yep, it's working quite smoothly so far =)

[9:10] Creem Pye: Babbage, do you expect the script memory limit wil be raised in teh future?

[9:10] Creem Pye: it would be nice if objects could consolidate their functions to a single script

[9:10] Babbage Linden: gabriel, si, daveh, vektor and periapse did a lot of work over the last year too

[9:10] Christos Atlantis: I think I have skid marks on my forehead

[9:10] Tegg Bode: I think games would hae a better chance of working if we could reduce our continual downloading of textures by perhaps having a basic default texture set for walls & floors on our hard drives

[9:10] Creem Pye: (I imagine that without link messages etc, efficiency could be greatly improved)

[9:10] Babbage Linden: creem pye, that is also on our wish list

[9:10] Babbage Linden: proper script libraries

[9:11] Babbage Linden: so you can share code between scripts

[9:11] Babbage Linden: and develop general purpose libraries that can be used by other scripts

[9:11] Babbage Linden: instead of having to send them link messages

[9:11] Babbage Linden: or chat messages

[9:11] Creem Pye: even functions like llLinkParticleSystem() to set a particle system centered around a link in the object would be nice

[9:12] Creem Pye: instead of having to have a separate script in a child prim for particles, commanded by the main script through link messages

[9:12] Christos Atlantis: I have tried 5 times in my life to learn programing this is the closest to heaven for me, and for that I would like to thank you guys and the people that help in groups, like Jam and co

[9:12] Babbage Linden: glad to hear it christos!

[9:12] Jam Meili: uuh .. thank you :)

[9:12] Babbage Linden: :-)

[9:13] Bartlee Arai: will the old scripting engine be replaced eventually once transparency has been acheived?

[9:13] Gabriel Linden: teaching the world to code

[9:13] Christos Atlantis: your both welcome, its amazing to see what can be done

[9:13] Jam Meili: and yes, mono is a great improvement even it has some beginning problems (that will sure be fixed)

[9:13] Babbage Linden: ok, we should wrap up there i think

[9:13] Babbage Linden: so gabriel and i can get back to fixing bugs

[9:14] Christos Atlantis: ty for for your time

[9:14] Babbage Linden: if you find any problems, please file them in to jira

[9:14] Imaze Rhiano: ya...and I need to go shopping new clothes... :P

[9:14] Babbage Linden: and we'll get on them as soon as possible

[9:14] Nock Forager: Thanks for very interestin meeting :)

[9:14] Babbage Linden: and if you see a repro for http://jira.secondlife.com/browse/SVC-2908

[9:14] Babbage Linden: please let us know

[9:14] Christos Atlantis: nice seeing you all here

[9:14] Miya Watanabe: thank you for the meeting

[9:14] Babbage Linden: hopefully i'll see you all here next week

[9:14] Babbage Linden: thanks for coming

[9:14] Gabriel Linden: thanks, and cya'all around

[9:15] Tegg Bode: Thanks both of you for your efforts :)

[9:15] Creem Pye: thanks for your help!

[9:16] Imaze Rhiano: does Mono have metaobject in Jita?

[9:17] Babbage Linden: yes

[9:17] Nock Forager: ah Babbage, Don't you mind if I put this office hour log on your wiki profile page?

[9:17] Babbage Linden: http://jira.secondlife.com/browse/SVC-1276

[9:17] Babbage Linden: is the beta jira

[9:17] Babbage Linden: nock, that's fine

[9:17] Babbage Linden: it will save me a job :-)

[9:17] Babbage Linden: i'll leave my bear here

[9:17] Nock Forager: :)

[9:17] Babbage Linden: to auto return in 15 minutes

[9:17] Christos Atlantis: :)

[9:18] Babbage Linden: there you go

[9:18] Babbage Linden: should be copyable

[9:18] Babbage Linden: or you can buy it for 0L$

[9:18] Christos Atlantis: AWSOME

[9:18] Christos Atlantis: ty :)

[9:18] Babbage Linden: ok, see you all next week

[9:19] Imaze Rhiano: bye

[9:19] Keimar Kuhn: bye