User:Babbage Linden/Office Hours/2009 04 22

From Second Life Wiki
Jump to navigation Jump to search

Transcript of Babbage Linden's office hours: 

 Topics
 * Let's watch Babbage talk video on lang.net :) LINK
 * "We've already done 90% of the work required to support cli languages in second life" LINK
 * Handling vehicles on script memory limitation. LINK
 * Yay thanks to Yahoo pipes! LINK


[3:11] Kephra Nurmi: moin babbage, trinity & qie

[3:11] Babbage Linden: hi everyone

[3:11] SirMartinRJ Lupindo: Hello

[3:11] TEB Skytower: hi there

[3:11] Chieron Tenk: hiyas

[3:11] Babbage Linden: first off, apologies if you came along last week of the week before

[3:11] Babbage Linden: i was on the west coast, so didn't make my office hours

[3:11] Babbage Linden: and forgot to let you know

[3:12] Babbage Linden: so, sorry about that

[3:12] Qie Niangao: just glad to have you this week :)

[3:12] Trinity Coulter: its ok... i was probably asleep for 90% of them :)

[3:13] Babbage Linden: i was at lang.net 2009 last week at microsoft talking about mono in second life

[3:13] Babbage Linden: the video is online here if you'd like to watch my talk: http://download.microsoft.com/download/B/F/0/BF0DAE51-F096-4DB4-8707-ACBDB7680BC0/17-JimPurbrick-SecondLife.wmv

[3:13] Babbage Linden: it was a very useful t

[3:13] Babbage Linden: rip

[3:14] Babbage Linden: i was able to talk to people about continuations in the cli

[3:14] Babbage Linden: (which is what we use for microthreading mono)

[3:14] Babbage Linden: and ask about whether we can support the dlr languages

[3:14] Babbage Linden: iron python and iron ruby

[3:15] Kephra Nurmi: is cil able to run duck typing languages, like smalltalk or ruby?

[3:16] Babbage Linden: kephra, yes

[3:16] Babbage Linden: the way it's made efficient is by the dlr generating code at run time

[3:16] Babbage Linden: which is a problem for us

[3:16] Babbage Linden: as we need to inject microthreading in to the bytecode

[3:17] Babbage Linden: with lsl and c# we generate an assembly from the compiler

[3:17] Babbage Linden: and then rewrite it

[3:17] Babbage Linden: before we run it

[3:17] Babbage Linden: with ironpython and ironruby

[3:17] Babbage Linden: extra code is generated at run time

[3:17] Babbage Linden: so we need a way to intercept that code

[3:17] Babbage Linden: and rewrite it as well

[3:17] Babbage Linden: which makes it more complicated to support

[3:18] Babbage Linden: so, it's likely that we'll support c# and maybe f# first

[3:18] Babbage Linden: as they're more static and generate assemblies we can rewrite

[3:18] Kephra Nurmi would prefer lisp and smalltalk ;)

[3:18] Babbage Linden: there should be ways to rewrite the iron languages on the dlr

[3:18] Babbage Linden: but it will be more complicated

[3:18] Babbage Linden: i talked to gilad bracha at lang.net

[3:19] Babbage Linden: who is building his new language, newspeak on top of the smalltalk squeek vm

[3:19] Babbage Linden: squeek makes it much easier to capture stack frames

[3:19] Babbage Linden: without having to do the code rewriting we have to do in the cli

[3:20] Babbage Linden: but, it's mostly a toy vm used for education

[3:20] Babbage Linden: it doesn't support the sandboxing that the cli provides

[3:20] Babbage Linden: which was one of the main reasons we wanted to use mono

[3:20] Catherine Pfeffer: (Sorry to be a joykiller, but I still think developper resources would be much better used if adding the missing bits in LSL and fixing the bugs, rather than adding new languages)

[3:20] Babbage Linden: i disagree catherine

[3:21] Babbage Linden: lsl has lots of horrible inconsistencies and corner cases

[3:21] Babbage Linden: that make it very difficult to work with or extend without breaking features

[3:21] Babbage Linden: also, one of it's few advantages is that it's small and simple

[3:21] Babbage Linden: if you were to extend it you'd end up with a broken, inconsistent, complex language

[3:21] Catherine Pfeffer: LSL is simple, ok not perfect, but has a lot of qualities. For example it is events oriented, and the external structure is a machine state, which makes it perfect for its task

[3:22] Babbage Linden: the scripting environment in second life is good

[3:22] Babbage Linden: the lsl language isn't

[3:22] Babbage Linden: if we added support for other cli languages to second life

[3:23] Catherine Pfeffer: There are issues with 100+ votes I can't get a linden to finsih the missing bits because of "missing developer resources". So, even if you are right that new languages "would be nice", taht's a matter of priorities

[3:23] Babbage Linden: they would still share the event oriented environment

[3:23] Babbage Linden: catherine, we already have a prototype implementation of c# scripting in second life

[3:23] Catherine Pfeffer: yeah, and do an even waiting loop, and maintain the states in variables ? That would e a step backwards.

[3:24] Babbage Linden: the way we have implemented mono, it's just another source of cli assemblies to rewrite

[3:24] Babbage Linden: the simulator and uthread injector don't care whether the assemblies come from an lsl or c# compiler

[3:24] Catherine Pfeffer: [3:23] Babbage Linden: catherine, we already have a prototype implementation of c# scripting in second life <== yes I know. My remark was more a ranting than a real suggestion because of that. Hence the parentheses.

[3:24] Babbage Linden: or f# or boo

[3:25] Qie Niangao: well, I have to agree with Catherine on this: at least from the scripter's perspective, there's a desperate need for more ll* functions, completely independent of LSL as a language.

[3:25] Babbage Linden: i also don't agree that states are better than variables

[3:25] Catherine Pfeffer: Thanks Qie

[3:25] Babbage Linden: state changes are effectively long jumps with pretentions

[3:25] Babbage Linden: jumping out of a function halfway through is a horrible thing to do

[3:26] Catherine Pfeffer: Simple things too, like new parcel flags. Or simple features, like default permissions when building. Things for which we even provide the client-side patches, but can't get the final work to be done server-side.

[3:26] Babbage Linden: and the clearing of events that occur on state changes is not consistent either

[3:26] Babbage Linden: which is why you can't actually use states if you're dealing with money anyway

[3:26] Qie Niangao: yes, that state-change event handling is a mess, that's for sure.

[3:26] Sleeves Rhode: once C# is in, will it be easier to implement some of the long promised/broken/ignored ll* functions?

[3:27] Catherine Pfeffer: I agree, it is not consistent. I know what happens at state changes (timers, permissions, animations, etc.) and that was horrible to learn. I did not say LSL was perfect.

[3:27] Babbage Linden: we're not planning on doing a lot of extra work to support new languages

[3:27] Babbage Linden: we're mostly waiting on mono to finish their metadata verifier

[3:28] Babbage Linden: once that's done it's less work to support c# than to add new constructs to lsl

[3:28] Babbage Linden: and a lot less likely to break existing scripts

[3:29] Babbage Linden: going to lang.net was mostly about keeping up with what is happening on the cli platform

[3:29] Babbage Linden: and letting microsoft and others know what we've been up to

[3:29] Babbage Linden: which resulted in some interesting leads

[3:30] Babbage Linden: one interesting possibility is the use of boo to design domain specific languages

[3:30] Babbage Linden: as boo is another static language that runs on the clr

[3:31] Babbage Linden: adding support for it would allow residents to define their own domain specific languages in second life

[3:31] Babbage Linden: which would be very interesting

[3:31] Babbage Linden: as i've often thought that the actor based script model for second life worked well

[3:31] Babbage Linden: but the language wasn't as good a fit

[3:32] Catherine Pfeffer: We don't really need new "constructs". We need things like PARCEL_DETAILS_UUID (jira svc-1638) which are "apparently" not hard to implement and that we've been waiting for years

[3:32] Babbage Linden: using boo you would be able to define languages to describe virtual ecosystems in second life or whatever

[3:32] Catherine Pfeffer: believe me, if server code was open source, that would have been solved for very long... and this one is only one out of many examples

[3:32] Babbage Linden: catherine, languages and library calls are mostly orthogonal

[3:33] Babbage Linden: adding new library calls can be done relatively easily

[3:33] Catherine Pfeffer: yes, but human task force is interchangeable

[3:33] Qie Niangao: that's exactly the point: we need library calls much more than we need new languages.

[3:33] Kephra Nurmi: or the client side implementation to support them

[3:34] Babbage Linden: new library calls are being implemented

[3:34] Babbage Linden: http in is on it's way to the main grid

[3:34] Catherine Pfeffer: Thanks Qie. I don't say LSL is perfect or that other languages are not appreciated. I say there are things more urgent, even though i guess they are much less exciting from a software engineer point of view

[3:35] Babbage Linden: catherine, hardly any work is being done on any kind of scripting improvements at the moment

[3:35] Babbage Linden: languages or library calls

[3:35] Babbage Linden: most of the server side work is on stability

[3:35] Qie Niangao: yes, http-in is a good advance... but there's a huge backlog (and there'd be an even larger one, if scripters started to see that backlog getting worked)

[3:35] Babbage Linden: (1.26 reduced the simulator crash rate enormously)

[3:35] Babbage Linden: and scalability

[3:35] Catherine Pfeffer: http ? I am having a problem getting one call from UDP to HTTP + capabilities. One hour work at most. It what's took opensim folks to implement it.

[3:36] Babbage Linden: (lots of work is going in to spliting databases in order to allow second life to scale further)

[3:36] Babbage Linden: going to lang.net is mostly about leveraging the work we've already done in adding mono support

[3:37] SirMartinRJ Lupindo: I think that the improvement of the client/server is more important than improvement of existing capabilities for users (like LSL), Catherine

[3:37] Kephra Nurmi: the focus on stability over features is a good thing ... if I compare crashes two years ago an now

[3:37] Babbage Linden: given that we've already done 90% of the work required to support cli languages in second life

[3:37] Babbage Linden: i think it would be a shame to only support lsl

[3:37] Babbage Linden: but, any further work we do on scripting

[3:38] Babbage Linden: will be weighed up against adding new library calls

[3:38] Kephra Nurmi: wont it be easier to use old lsl bytecode and implement fancy language compilers client side?

[3:38] Babbage Linden: or working on other aspects of second life

[3:38] Babbage Linden: kephra no

[3:38] Babbage Linden: the easiest thing to do would be to allow cli assembly upload

[3:38] Babbage Linden: then people could use whatever compiler they liked

[3:38] Qie Niangao: one way to identify needed library functionality is to look at what functional bots are doing in-world. there's just no reason the grid should have to absorb the overhead of group-invite bots, at this late date.

[3:38] SirMartinRJ Lupindo: :D

[3:38] Babbage Linden: in whatever language they liked

[3:38] Babbage Linden: and second life wouldn't care

[3:39] Kephra Nurmi: *hm* cli upload sounds dangerous?

[3:39] Catherine Pfeffer: sirmartin : yes, absolutely. I was precisely to an imrpovement of client server (vwr-8049 / svc-3046). 95 votes, submitted 1 year ago, all client side patches written. just blocked because of server side code.

[3:39] Babbage Linden: but, to get to that point we need to have high confidence in the mono verifier

[3:39] Babbage Linden: which is still being worked on

[3:39] Babbage Linden: not by us

[3:39] Babbage Linden: once it's done we'll evaluate it

[3:40] Babbage Linden: and see if we can open up that facility

[3:42] Qie Niangao: so... i don't want to screw up the agenda, but I have a specific concern about the script memory limits, if that's in-order now.

[3:42] Babbage Linden: sure, qie

[3:42] Qie Niangao: (wall o' text) : I'm a concerned about the impact on vehicles of the coming memory limits, specifically the need to fix some deep design issues underlying SVC-22 *first*. That defect has to do with a race condition between knowing that a prim assembly arriving in a sim has an avatar attached so the prims can be associated with the avatar before denying entry to a full parcel. The concern is that memory-limited scripts will suffer the same race condition as prims. (With script URL resources for http-in it never mattered because one must llRequestURL() in the new sim.)

[3:43] Babbage Linden looks at SVC-22

[3:44] Babbage Linden: vehicles are a difficult case

[3:44] Babbage Linden: there is little in the code that defines them

[3:45] Babbage Linden: which makes it difficult to tell if something is a sofa (should be counted against parcel resources) or a car (should be independent)

[3:45] Catherine Pfeffer: correct. I have scripted some vehicles only with dynamics functions without the use of the specialized VEHICLE functions

[3:45] Trinity Coulter: I have a quick question in a bit, if you wouldn't mind....

[3:45] Qie Niangao: right, well, it's really any linkset assembly including an avatar, I think.

[3:45] Qie Niangao: as far as I can tell, the approach to addressing the race condition so far has been to just try to speed up the sim's re-assembly of the arriving prims... that hasn't worked out so well.

[3:45] Babbage Linden: i think what we did with script URL resources is to lazily shift pools as required

[3:46] Qie Niangao: right, that's what's worrisome...

[3:46] Babbage Linden: so, the vehicle would try to use the parcel pool

[3:46] Babbage Linden: and fall back to using the avatar pool if the parcel pool couldn't satisfy the resources

[3:46] Catherine Pfeffer: It worse than that Qie... most vehicles are a linkset + an avatar sitting, but some vehicles (like flight feathers or some rockets) are attachments to the avatar...

[3:47] Babbage Linden: which means that if your vehicle is not an attachment

[3:47] Qie Niangao: oh, gee, I hadn't even thought about the attachment condition.

[3:47] Babbage Linden: you have to have somewhere to rez it where it can use parcel resources

[3:47] Babbage Linden: a sandbox or some land you can own or use

[3:47] Babbage Linden: but, once you're sitting on it, it will be able to use your avatar resource pool if it needs to

[3:48] Babbage Linden: allowing you to move wherever you like

[3:48] Babbage Linden: attachment vehicles will always use your avatar pool

[3:48] Qie Niangao: that's fine... it's the sim border-crossing case I'm concerned about. presumably the accepting sim will have to solve the resource pool condition all over again.

[3:48] Babbage Linden: so are less problematic

[3:48] Babbage Linden: and sofas will be using the resources of the parcel they are rezzed on

[3:48] Babbage Linden: so, will just work

[3:49] Babbage Linden: i agree that SVC-22 needs to be fixed as part of this by the looks of it

[3:49] Babbage Linden: thanks for pointing it out

[3:49] Qie Niangao: thanks, Babbage. :)

[3:50] Babbage Linden: looks like it's being worked on

[3:50] Babbage Linden: i'll make sure there's a dependency on the script limits work

[3:50] Qie Niangao smiles.

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

[3:50] Babbage Linden: anyone else have something they'd like to talk about?

[3:51] Qie Niangao: Trinity, you had a question?

[3:51] Trinity Coulter: i have always wondered if you will let things like XML be read by llHTTPRequest... lots of web based things come back as XML, but LSL just rejects it out of hand

[3:51] Trinity Coulter: it just text, so why not

[3:51] SirMartinRJ Lupindo: ^^

[3:51] Babbage Linden: it's probably based on the content type

[3:51] Trinity Coulter: yes, it is

[3:52] Babbage Linden: also, XML tends to be too verbose for LSL scripts to deal with

[3:52] Babbage Linden: i had a conversation with someone on the yahoo pipes team about this a couple of years ago

[3:52] Babbage Linden: and they added a convert to CSV filter in yahoo pipes just for us :-D

[3:52] Trinity Coulter: i've wanted to work with APIs from some places and its pretty much impossible unless you set up your own webserver, just because of that 1 thing

[3:53] Babbage Linden: so, i would recommend piping your XML through a yahoo pipe, convering it to CSV (and filtering out the bits you don't need)

[3:53] Babbage Linden: then sending it to the LSL script

[3:53] Babbage Linden: if all you need to do is convert from XML, I would recommend looking at pipes

[3:53] Catherine Pfeffer: babbage : csv does not accept tree structures like XML, it only accept flat structures

[3:53] Catherine Pfeffer: +s

[3:53] Babbage Linden: if you need to do more than that, you may need an external web server

[3:54] Trinity Coulter: i just want to store a notecard key, for example

[3:54] Trinity Coulter: it would be nice to have a few properties of avies that are writable... like where we can stuff a litle bit of data like a UUID

[3:54] Trinity Coulter: since avatars are something that doesn't ever change its key

[3:55] Babbage Linden: catherine, correct, but there are many jobs you want to do with XML that don't rely on the tree structure

[3:55] Babbage Linden: often you're using xpath to pull out particular bits from the tree, for example

[3:55] Trinity Coulter: prims have properties, why not avies too :)

[3:55] SirMartinRJ Lupindo: yes

[3:55] Babbage Linden: but, yes, supporting XML might make sense

[3:55] Catherine Pfeffer: Babbage : the angles bracket tax is not that heavy, and XML has a lot of applications and is widely adopted

[3:56] Babbage Linden: especially when scripts can use more memory

[3:56] Catherine Pfeffer: (lol, correct... memory and XML, uuuuh)

[3:56] Trinity Coulter: i just really am trying to avoid the whole chicken and egg thing when trying to set up a server prim since you have to get the UUID of the prim to the vendors, etc

[3:57] Trinity Coulter: and it seems like overkill to have to set up a whole external webserver infrastructure to store 1 UUID

[3:57] Kephra Nurmi is currently playing around with using Wiki's (there are thousands of them) as a cloud database for SL ... just to solve those problems ;)

[3:58] Babbage Linden: trinity, i anticipate a number of services that support HTTP in URL mapping

[3:58] Babbage Linden: which would solve your problem

[3:58] Trinity Coulter: i tried doing that with the SL wiki, Kephra... but they turned off writing from LSL scripts to the wiki

[3:58] Babbage Linden: i was planning to write an host one myself

[3:58] Trinity Coulter: i was going to use my user page to store information on the wiki

[3:58] Babbage Linden: the script requests an HTTP url, registers it with the service

[3:59] Babbage Linden: clients request a long lived name from the service

[3:59] Babbage Linden: which just redirects the request to the current HTTP in URL

[3:59] Trinity Coulter: yes, i tested that on the beta grid... a few of those short URL services have APIs.... but guess what.... the return XML

[3:59] Trinity Coulter: *they

[3:59] Trinity Coulter: which gets tossed by LSL

[3:59] Trinity Coulter: :)

[3:59] Babbage Linden: so, it seems like i need to write a Second Life specific one after all

[4:00] Babbage Linden: :-D

[4:00] Trinity Coulter: or just allow XML to come in

[4:00] Babbage Linden: the former is the short term fix

[4:00] Babbage Linden: allowing XML in is a longer term solution

[4:01] Babbage Linden: ok, we're out of time

[4:01] Trinity Coulter: :)

[4:01] Babbage Linden: thanks for coming everyone

[4:01] Sleeves Rhode: thanks Babbage :)

[4:01] Trinity Coulter: ty Babbage :)

[4:01] Trinity Coulter: very interesting :)

[4:01] Catherine Pfeffer: Thanks Babbage for your listening and answering

[4:01] Thirandaz Elephas: Thank you

[4:01] Kephra Nurmi: perhaps i manage to come more often ;)

[4:01] Nock Forager: Thanks babbage.

[4:01] Xah Toll: thank you

[4:01] Thirandaz Elephas: How often are these office hours?

[4:01] Catherine Pfeffer: Lunch time ;-)

[4:02] Catherine Pfeffer: bye everyone & thx again Babbage

[4:02] Kephra Nurmi: cu babbage ... and thanks ;)
Retrieved from "https://wiki.secondlife.com/w/index.php?title=User:Babbage_Linden/Office_Hours/2009_04_22&oldid=329402"