User:Babbage Linden/Office Hours/2009 05 20

From Second Life Wiki
Jump to: navigation, search

Transcript of Babbage Linden's office hours:

[3:12] Gunter Vandyke: Hi Babbage

[3:12] Xugu Madison: hey Babbage!

[3:12] Babbage Linden: hiya

[3:12] Imaze Rhiano: hi babbage

[3:12] Soph Oh: hi

[3:12] Ciao Wise: hi babbage

[3:12] Thunderclap Morgridge: Hello!

[3:13] Babbage Linden: so, updates from last week

[3:13] Babbage Linden: we've had a meeting with jack about script limits

[3:13] Media Hax: I would like to report these people for talking smack about my beloved LSL...

[3:13] Babbage Linden: there's still some further analysis needed on the memory numbers

[3:14] Babbage Linden: which is going to happen

[3:14] Babbage Linden: and jack has some use cases for estate owners that we need to look at

[3:14] Babbage Linden: can you rent out land and still have the ability to run scripts for example

[3:15] Babbage Linden: so. we're going to look at his advanced user use cases and see if our proposal can handle those

[3:15] Babbage Linden: we're also thinking about what to do about LSO

[3:16] Babbage Linden: as we want to make sure we don't incentivise the use of LSO over mono

[3:16] Xugu Madison: LSO being the old engine?

[3:16] Babbage Linden: yes

[3:16] Babbage Linden: we're currently thinking about setting the cost of LSO scripts to be 128KB

[3:17] Babbage Linden: which will mean that mono scripts will always be more memory efficient

[3:17] Thunderclap Morgridge: thats for all los scripts

[3:17] Pants Lilliehook: leading from that, will scripts compiled from inventory be compiling in mono soon? or an option to do so?

[3:17] Babbage Linden: which will create an incentive to use mono and migrate to it

[3:17] Babbage Linden: without forcing people to switch to mono immediately

[3:17] Imaze Rhiano: but when 64 bits server code hits online - mono scripts are also going to use 128kb?

[3:18] Babbage Linden: imaze, yes in the worst case 64bit mono scripts will use 128KB of memory

[3:18] Babbage Linden: but the other thing we're thinkging about doing is adding a library function to request a memory allocation for a script

[3:18] Xugu Madison: Do you have any numbers for typical Mono/LSO memory differences?

[3:18] Babbage Linden: so, simple mono scripts will be able to request 16KB of memory

[3:19] Xugu Madison: I'd make it a property on the script asset, myself....

[3:19] Babbage Linden: and then end up costing a lot less than an LSO script priced at 128KB

[3:19] Babbage Linden: you will also be able to request 4MB of memory of a mono script if you want to

[3:20] Babbage Linden: and have it available

[3:20] Pants Lilliehook: :)

[3:20] Thunderclap Morgridge: how much memory do current Lso scripts use?

[3:20] Babbage Linden: which will mean that you don't have to split scripts up to build big systems

[3:20] Babbage Linden: currently all LSO scripts use 16KB of memory

[3:21] Babbage Linden: mono scripts can use up to 64KB of memory

[3:21] Babbage Linden: but the memory is allocated dynamically

[3:21] Babbage Linden: so, on average they end up using less than 16KB

[3:21] Babbage Linden: even if they are using 64 bit references

[3:22] Thunderclap Morgridge: do you have any time frame on the memory pool implementation?

[3:23] Babbage Linden: well it's actually built already, and being used for http-in url limiting

[3:23] Thunderclap Morgridge: ok

[3:23] Soph Oh: is 64 bits server can allow to use number (integer) more than the actual integer 32 limit ?

[3:24] Babbage Linden: soph, no the types remain the same

[3:24] Babbage Linden: it's just reference sizes that change

[3:24] Soph Oh: ok

[3:24] Imaze Rhiano: I suggested this in earlier office hour - but how about adding abstract "performance cost" value meter for scripts - that would be calculated from memory usage, functions it calls and other parameters that can cause SIM lag? That would allow to better distuinguish difference between 128kb LSO and 128kb MONO - and script customers would need to compare only single value. (And you could adjust abstract value in future, when server code/hardware/architecture changes).

[3:25] Xugu Madison: Possibly a CPU time used in last 24 hours/averaged across entire runtime, display?

[3:26] Babbage Linden: imaze, it's an option, but we've had problems in the past coming up with abstract costs like parcel dwell

[3:27] Xugu Madison: It's my eternal question at these things, but any news on non-LSL language support? :)

[3:27] Xugu Madison: particularly C# API release?

[3:27] Babbage Linden: prim limits are easier to reason about

[3:28] Babbage Linden: xugu, i totally failed to catch up with robla about the C# api questions

[3:28] Thunderclap Morgridge: so C# use is being considered?

[3:28] Xugu Madison: Ah well...

[3:29] Media Hax: Xugu, eat ur LSL...

[3:29] Media Hax: tits delicious

[3:29] Babbage Linden: will try to find out this week

[3:29] Xugu Madison: Beyond that, can I say... new functions getting into LSL seems to be incredibly slow. IS it a lack of dev time, or perceived need, or...?

[3:30] Xugu Madison: http://jira.secondlife.com/browse/SVC-224 being a particular pet peeve

[3:30] Babbage Linden: xugu, it's often a lack of QA time

[3:31] Babbage Linden: we've been having a lot of features getting pushed out of release recently because we just have too many changes to ship

[3:31] Babbage Linden: and lsl functions are pretty low down the list of priorities at the moment

[3:31] Thunderclap Morgridge: that seems to be the way everywhere

[3:31] Babbage Linden: the deferred rendering is another good example

[3:32] Babbage Linden: i saw the first screen shots of it last april

[3:32] Babbage Linden: and it's only just available as a debug option

[3:32] Babbage Linden: we're getting better though

[3:32] Babbage Linden: with lots more automated testing

[3:32] Babbage Linden: we should be able to ship code faster

[3:32] Xugu Madison: Is there any chance of seeing more stuff pushed through to the beta grid so we can dabble?

[3:32] Xugu Madison cheers for automated testing

[3:33] Thunderclap Morgridge: agrees

[3:33] Babbage Linden: the other problem with new features, especially lsl functions is that they get relied on

[3:33] Media Hax: hmmm... good issue there Xugu.... svc-224

[3:33] Babbage Linden: making sure we get them right is very important

[3:33] Babbage Linden: we have too many functions that nearly worked, but have bugs that are relied on

[3:34] Xugu Madison: http://jira.secondlife.com/browse/SVC-636 also - a lot of people want a Twitter HUD, for example, and the only way right now is to re-wrap things through an external webapp

[3:34] Pants Lilliehook: lol @ relied on bugs

[3:34] Pants Lilliehook: hehe

[3:34] Thunderclap Morgridge: henes the screaming in other areas

[3:34] Xugu Madison nods "Ah, yes, I can see that..."

[3:35] Babbage Linden: xugu, tes

[3:35] Media Hax: Yes Babage, the 'Bug' issue is exactly in play in my SVC-4133... http://jira.secondlife.com/browse/SVC-4133

[3:35] Babbage Linden: you might be able to do something with yahoo ipies

[3:35] Babbage Linden: pipes, even

[3:35] Thunderclap Morgridge: i have a twitter hud its was made by Oridnal but it works

[3:36] Babbage Linden: it's still an external web service, but not one you need to host

[3:36] Babbage Linden: or build

[3:36] Xugu Madison: I tried pipes, but had no way of getting input back to Twitter if I remember correctly

[3:36] Media Hax: yahoo dev site is great, just started stealing stuff, i mean using stuff there...

[3:36] Xugu Madison: Thunderclap, yes, but it's still not good having to go through a 3rd party site, especially sending passwords around

[3:36] Babbage Linden: agreed

[3:37] Babbage Linden: once we have large memory support

[3:37] Babbage Linden: we should up the limits on http out

[3:37] Babbage Linden: and allow xml support

[3:37] Babbage Linden: as it will be possible to actually consume reasonable sized xml documents without running out of memory

[3:37] Xugu Madison: I don't actually need the limits up, cutting hard after however many bytes is okay, I just want to be able to get the first few hundred bytes :)

[3:38] Thunderclap Morgridge: I would love streaming video from someone other than quicktime and youtube without losing clumps of my hair

[3:38] Babbage Linden: well, that's beyond my area thunderclap

[3:38] Thunderclap Morgridge: I know

[3:38] Babbage Linden: but there is lots of work going on with media in sl at the moemnt

[3:38] Devilman Kohime: I would like to know if there is anything planed to make a professioneller menu. Checkboxes, Comboboxes and so on.

[3:39] Imaze Rhiano: I would love to see VNC media textures :P

[3:39] Xugu Madison saw a llTextbox around somewhere - did wonder where that got to http://wiki.secondlife.com/wiki/LlTextBox

[3:39] Soph Oh: and the llTextBox function ?

[3:39] Soph Oh: lol

[3:39] Media Hax: Who is doing this media work Babbage?

[3:39] Babbage Linden: howard and the viewer team

[3:39] Babbage Linden: callum too

[3:40] Media Hax: Because I am having huge content breakage since 1.26, and no one at LL seems to care

[3:40] Pants Lilliehook: +1 to Devilman's question :)

[3:40] Devilman Kohime: :)

[3:40] Babbage Linden: scripted ui is an interesting question

[3:40] Thunderclap Morgridge: oh they care..just sometimes in the wrong direction

[3:40] Babbage Linden: there are lots of ui changes happening at the moment

[3:41] Pants Lilliehook: ah, so it might fit into a large space ship related avenue...

[3:41] Thunderclap Morgridge: excluding the adult changes do you know what else

[3:41] Xugu Madison would kill for client-side scripting, but suspects it'll come around the point we get Mono bytecode verification

[3:41] Media Hax: Well, they wiped out 2 years of my work and i3D's work... right into the toilet

[3:41] Babbage Linden: it would be nice to be able to run scripts on the client that could build ui

[3:41] Babbage Linden: we've done some work embedding mono on the viewer to allow that

[3:41] Babbage Linden: but it's a long way off

[3:41] Pants Lilliehook: ok, happy to hear its in the pipeline Babbage

[3:42] Xugu Madison: Things I want to get you pondering in a long term way, Babbage. Script signing (so modifiying a script after the author signs it removes the signature). RPC instead of chat/link messages. IM to scripts, from avatars (so bi-directional).

[3:42] Babbage Linden: alternatively being able to open web pages in the client and extract events would allow web uis

[3:42] Pants Lilliehook: yeah, web hosted UIs would be much nicer than blue boxes

[3:43] Thunderclap Morgridge agrees

[3:43] Babbage Linden: just being able to build huds and interact with them with client scripts would be a big improvement

[3:44] Babbage Linden: so, huds, web and widgets: 3 ways to build uis unfortunately

[3:44] Imaze Rhiano: would also reduce sim load

[3:44] Thunderclap Morgridge agrees again

[3:44] Pants Lilliehook: lovely :)

[3:44] Babbage Linden woudl like 1 way to do things

[3:44] Devilman Kohime: Would make many things much easier :)

[3:44] Thunderclap Morgridge would love to be able to bring widgets in world

[3:44] Pants Lilliehook: options are good for us, but harder for you

[3:44] Gunter Vandyke: agreed

[3:45] Babbage Linden: the client/server subjective/objective split also complicates things

[3:45] Babbage Linden: sometimes you want private ui

[3:45] Babbage Linden: sometimes you want shared ui

[3:45] Pants Lilliehook: we don't want much eh

[3:45] Pants Lilliehook: hehe

[3:46] Babbage Linden will have another look at this once the current ui work has died down

[3:46] Xugu Madison wants the world. On a plate.

[3:46] Pants Lilliehook: u can have it on a prim Xugu, and it can rotate :)

[3:47] Xugu Madison: Pants, sounds likje good compromise

[3:48] Thunderclap Morgridge: that jir is an awesome idea

[3:48] Thunderclap Morgridge believes his sculptie plates are another whole issue entirely

[3:48] Imaze Rhiano: what jira?

[3:49] Thunderclap Morgridge: the one posted earlier

[3:49] Thunderclap Morgridge: i opened it in the media browser

[3:49] Babbage Linden: ok, we have 10 minutes left

[3:50] Gunter Vandyke: will there be a option in LSL to get the name of an attachment a avatar wears

[3:50] Babbage Linden: anything else we should talk about?

[3:50] Babbage Linden: gunter, can't you use sensors for that?

[3:50] Xugu Madison: Oh, another long LONG term thing to ponder Babbage; renting MySQL server space from LL and adding SQL support to scripting

[3:50] Gunter Vandyke: mean on others

[3:50] Thunderclap Morgridge: know anything about Prospero recientence on the 1000 prim coalesced issue?

[3:51] Babbage Linden: xugu, there has been talk about that

[3:51] Thunderclap Morgridge: its the only screaming as loud as the adult issues

[3:52] Xugu Madison: Babbage, awesome, in a "Oh no, we're all going to die in a massive injection attack" way

[3:52] Imaze Rhiano: is avatar average memory usage still 3MB per avatar? or have you yet refined more accurate numbers from memory usage data?

[3:52] Babbage Linden: imaze, i think that was a maximum size

[3:53] Babbage Linden: i haven't done much more analysis on the numbers

[3:53] Babbage Linden: alex is looking at refining them more

[3:53] Imaze Rhiano: I think that it was average from 40 avatars

[3:54] Imaze Rhiano: oookay.. so we wait results then :P

[3:54] Babbage Linden: yes, sorry

[3:54] Imaze Rhiano: how is http-in?

[3:55] Babbage Linden: i've spent most of my week on http textures and web services

[3:55] Babbage Linden: http-in is done and waiting deployment as far as i'm aware

[3:55] Thunderclap Morgridge: oooh

[3:55] Devilman Kohime: A great thing would be something like creating own classes and methods for LSL. But I guess this will be a long way.

[3:55] Xugu Madison: Web services? Such as? :)

[3:56] Babbage Linden: mostly internal services

[3:57] Babbage Linden: fronting data bases and used by simulators

[3:57] Xugu Madison: Ah well

[3:57] Babbage Linden: but, there are plans to open those services up from the web in the future

[3:57] Thunderclap Morgridge: its still good

[3:57] Babbage Linden: to start with they're a way for us to scale out data stores beyond mysql.agni

[3:57] Babbage Linden: and it's going to be a big project

[3:58] Xugu Madison: It's definitely good seeing more web services around generally, it would be nice to get more control over SL from external services

[3:58] Media Hax: when will http allow textures from outside sources?

[3:58] Xugu Madison would ask if you have an ETA for RegAPI 2, but thinks you may cry/explode