User:Babbage Linden/Office Hours/2009 11 04

From Second Life Wiki
Jump to navigation Jump to search

Transcript of Babbage Linden's office hours:

[3:12] JB Hancroft: hi Babbage

[3:12] lonetorus Habilis: XD

[3:12] Imaze Rhiano: hi Babbie

[3:12] Babbage Linden: sorry, i'm later, i had an interview

[3:12] JB Hancroft: 30k? woot!

[3:12] valentine Biddle: hai babbage

[3:12] Morgaine Dinova: Hiya Babbage!

[3:13] Jonit Ivory: did you get the job?

[3:13] Babbage Linden: and last week i was on holiday

[3:13] JB Hancroft hopes he was the "interviewer"

[3:13] Babbage Linden: i'll also be on holiday next wednesday

[3:13] Babbage Linden: (i have lots of built up vacation)

[3:13] lonetorus Habilis: slcker :P

[3:13] Sheryl Mimulus: that's close to 4GB of memory (64k heap, 64k code, 30,000 scripts)

[3:13] Babbage Linden: so, who would like to make a sign to say there won't be an office hour next week

[3:13] Babbage Linden: (bonus points if it looks at dopplr to see if I'm away)

[3:13] Babbage Linden: ;-)

[3:14] lonetorus Habilis: sheryl, i dont know how many scripts it was, but plenty to crash the sims, its hard to check inventory numbers with those number of scripts

[3:14] Babbage Linden: anyway, there's lots of news this week

[3:14] Kaluura Boa: Haaaa....

[3:14] Babbage Linden: i've been looking at the sim freezing with mono scripts

[3:14] Morgaine Dinova: Woot!

[3:14] Babbage Linden: it's down to 3 problems

[3:14] lonetorus Habilis: \o/

[3:14] JB Hancroft: huzzah!

[3:14] Babbage Linden: one is a problem with the scheduler

[3:14] Babbage Linden: which we already have fixed in a mono-scheduler branch

[3:15] Sheryl Mimulus: woot!

[3:15] Babbage Linden: we need to work out a good deploy plan for that fix as it will require people to retest scripts

[3:15] JB Hancroft: was there a jira on that? (would like to read that)

[3:15] Morgaine Dinova: It was scheduling new script loading exclusively?

[3:15] Babbage Linden: (if scripts rely on timing it may expose race conditions)

[3:15] Babbage Linden: some of the problems are due to verification

[3:15] Babbage Linden: that's what causes the big freezes due to people tping in with mono attachments

[3:16] Morgaine Dinova: It was done inline?

[3:16] Gunter Vandyke: hello all

[3:16] Babbage Linden: the reason we need to do digital signature verification currently is that we used to allow UDP uploads of scripts

[3:16] Babbage Linden: so we need to make sure that all scripts loaded in to the sim have been through our

[3:16] Babbage Linden: compiler, verifier, uthreadinjector pipeline

[3:17] Babbage Linden: we do that by signing them

[3:17] Babbage Linden: and checking the signature on load in to a sim

[3:17] JB Hancroft: no letting the nasties come in...

[3:17] Babbage Linden: which is cheaper than running the verifier every tmie

[3:17] Babbage Linden: but not cheap enough it seems

[3:17] Babbage Linden: there are a couple of options for fixing that

[3:17] Morgaine Dinova: The problem isn't cost though, is it? It's that it was being done inline.

[3:18] Babbage Linden: the first is to upgrade to mono 2.6

[3:18] Babbage Linden: which we'll be doing for C#

[3:18] Patnad Babii: woot

[3:18] Babbage Linden: and then using the built in CoreCLR security sandbox

[3:18] Babbage Linden: rather than checking scripts are safe in advance

[3:18] Patnad Babii: any time line on c# ?

[3:18] Babbage Linden: that will definitely happen, and will allow us to just turn off the signature checking

[3:18] Babbage Linden: but the time line for beta is still some time next year

[3:19] Babbage Linden: and it won't be in release for a while after that

[3:19] Sheryl Mimulus: I was monitoring a heavily loaded RP sim the other day.. on average each person was carrying 300 scripts..

[3:19] Babbage Linden: another option is to multithread task rezzing

[3:19] Babbage Linden: which needs to happen anyway

[3:19] Morgaine Dinova: But none of that is the key problem. The central issue is that all those things were being done inline instead of concurrently.

[3:19] Morgaine Dinova: Yeah, exactly.

[3:19] Babbage Linden: as rezzing many prims stalls the sim anyway

[3:20] Babbage Linden: there is planned work in that area, so i need to check the timeline

[3:20] Patnad Babii: is lsl will be capable of multithreading?

[3:20] lonetorus Habilis: yeah, the time of single thread sims are soon over, if we are to scale with current and future cpu developments

[3:20] Babbage Linden: another option is to ammeliorate the cost by spreading the verification over multiple frames

[3:20] Babbage Linden: but i'd rather not do that

[3:20] Babbage Linden: multithreading is the real solution

[3:21] Babbage Linden: the 3rd problem is with derez

[3:21] lonetorus Habilis hugs babbage

[3:21] Babbage Linden: where the sim will go through all pending delete tasks and clean them up in a single frame

[3:21] Babbage Linden: which, when there are many mono scripts to be deleted takes too long

[3:21] JB Hancroft: can you cache the results... that it's already been done by another sim, or do you have to do it on every TP?

[3:21] Babbage Linden: again that should be multi-threaded

[3:21] Babbage Linden: but could be ammeliorated by only removing N pending delete tasks per frame

[3:22] Babbage Linden: caching verification results might not be a bad idea

[3:23] Babbage Linden: but as we should not need the signature verification post C# I'm not sure I want to go there

[3:23] Sheryl Mimulus: makes sense, JB.. if another sim has already verified the scripts a few minutes ago, why verify them again?

[3:23] JB Hancroft nods...

[3:23] lonetorus Habilis: and now the obvious question, is there a tieline for fixing these 3 probems?

[3:23] Morgaine Dinova: Hiya Han

[3:23] Babbage Linden: it may be that we can only verify scripts coming from the asset server

[3:24] JB Hancroft: are we confident in the sandbox for CoreCLR - to let unvalidated scripts run after uplaod?

[3:24] Babbage Linden: scripts coming from other sims

[3:24] Han Sontse: Hi Morgaine

[3:24] Babbage Linden: (via a TP, wouldn't need verifying)

[3:24] Babbage Linden: a big part of the C# work is building confidence in the CoreCLR sandbox

[3:25] Han Sontse: is this a native code based solution?

[3:25] JB Hancroft: there is a 2 or 3-level security model there, right? Do you have plans on how to use them?

[3:25] Babbage Linden: I'm more confident in the CoreCLR sandbox than I am in being able to extend our current verifier to handle arbitrary CLI assemblies

[3:25] Babbage Linden: the sandbox is nice and simple

[3:25] Babbage Linden: code is either critical, secure critical or transparent

[3:25] Patnad Babii: any way to test this out yet?

[3:26] Babbage Linden: untrusted code created by compiling scripts is transparent

[3:26] Morgaine Dinova: Babbage, before dropping the verification, add a dummy OGP for when interop arrives -- check that it's not coming from a 3rd party Region Domain, since that would be outside your trust zone.

[3:26] Babbage Linden: and is not allowed to call critical code

[3:26] Morgaine Dinova: OGP check

[3:26] Babbage Linden: the safe critical code acts as the gateway

[3:26] Babbage Linden: transparent code can call it, it checks the arguments and then forwards the calls to the critical code

[3:26] Babbage Linden: which can call in to the simulator

[3:27] JB Hancroft: as a ring/gate type of function

[3:27] Babbage Linden: so, we take care in crafting the safe critical code

[3:27] Babbage Linden: to only allow calls to library code

[3:28] Babbage Linden: and not to assemblies that allow file access or other things we want to exclude

[3:28] Babbage Linden: the Mono team are marking up their assemblies to match the Silverlight sandbox

[3:28] Babbage Linden: we'll be defining one for C# scripts in SL

[3:29] Babbage Linden: that initially will only have access to the LSL library calls

[3:29] Babbage Linden: but we could slowly and carefully open up to allow access to other .NET libraries, like the collection classes for example

[3:29] Morgaine Dinova: Anyone have a link to the Silverlight sandbox stuff?

[3:29] Babbage Linden: we'll be able to steal many of the permissions from Silverlight I think

[3:30] Imaze Rhiano: moonlight in Mono

[3:30] JB Hancroft: http://msdn.microsoft.com/en-us/magazine/cc765416.aspx

[3:30] Morgaine Dinova: Babbage: but that's not been passed through ECMA, right?

[3:30] Babbage Linden: if you look at Silverlight developer documentation you'll be able to see what's available in Silverlight

[3:30] Babbage Linden: good point morgaine, i'll need to check on the status of the CoreCLR parts

[3:31] Aimee Trescothick: stealing permissions seems somewhat ironic

[3:31] Morgaine Dinova: lol

[3:31] Han Sontse: lol

[3:31] Babbage Linden: C# and the CLI are ECMA standards, I'm not sure about CoreCLR

[3:31] Babbage Linden: I'll check with Miguel

[3:31] lonetorus Habilis: i suppose copying would be a better term

[3:31] Imaze Rhiano: http://www.mono-project.com/Moonlight2CoreCLR

[3:32] Babbage Linden: so, freezes, that was the first topic

[3:32] Babbage Linden: we know what's causing them

[3:32] Babbage Linden: we have multiple ways to solve the problems

[3:32] Babbage Linden: i'll be having discussions internally to work out which solution we want to go for

[3:32] lonetorus Habilis: bababge, you sid scripts needed to be erset, cant this be done from the backend?

[3:32] Babbage Linden: and then will be able to give you and idea of timelines

[3:32] JB Hancroft: this is great progress... encouraging :)

[3:33] Morgaine Dinova: While dates are obviously inappropriate, do you expect any of these avenues to be actually product in the next few months?

[3:33] Babbage Linden: Karel Linden has also been making great progress reinstating TCMalloc in to the simulator as our memory manager

[3:33] JB Hancroft: (it sort of takes the wind out of my idea of used Commodore-64s as SL co-processors, though ;)

[3:33] Han Sontse: lol

[3:33] Babbage Linden: hopefully we'll be getting simulators using TCMalloc on to aditi this week

[3:33] Morgaine Dinova: Hehe

[3:34] Sheryl Mimulus: :P

[3:34] Babbage Linden: and will be testing performance versus the same regions on agni

[3:34] Liandra Ceawlin: Does that affect scripts at all?

[3:34] Babbage Linden: if that goes well we'll be rolling that out across the grid

[3:34] JB Hancroft nods... how will we be able to tell... what's the impact?

[3:35] Babbage Linden: TCMalloc implements more efficient memory management, so hopefully the simulators will run faster

[3:35] Babbage Linden: but more importantly it includes built in memory profiling

[3:35] Liandra Ceawlin: Hm, TCmalloc looks cool. Maybe I should try to stuff it into Emerald. >_>

[3:35] Han Sontse: in a loaded state or a unloaded state?

[3:35] Babbage Linden: so, once we have TCMalloc sims in production, we'll be able to see where the memory is going in bloated laggy sims

[3:36] Babbage Linden: which will help us fix any memory leaks that exist

[3:36] Babbage Linden: and also have more information for basing memory budget decisions on

[3:36] Babbage Linden: we'll be able to see in practice how much memory is being used by physics or scripts or interest list updates

[3:36] JB Hancroft: will there be any add'l information made available, for Residents to know where/how memory is being used?

[3:37] Babbage Linden: whereas at the moment we can only see the footprint of a simulator

[3:37] Han Sontse: ah

[3:37] Babbage Linden: and say "wow, that one's getting big"

[3:37] Morgaine Dinova: Hehe

[3:38] Han Sontse: so you can see which classes allocated memory.

[3:38] Babbage Linden: we have custom code to track script usage (which we'll be using to both set and track script limits) but we don't want to have to add custom code for every subsystem

[3:38] Babbage Linden: yes, exactly, it tells you how much memory is being used by each class

[3:38] Babbage Linden: amongst other things

[3:38] Han Sontse: ㋡

[3:39] Sheryl Mimulus: profiling ftw :)

[3:39] Babbage Linden: the final thing I have to talk about is efficient scripts

[3:39] JB Hancroft sits up...

[3:39] Babbage Linden: which is the project we're putting together to enable efficient scripting

[3:39] Han Sontse: lol

[3:39] Babbage Linden: which we really should do alongside script limits

[3:40] Sheryl Mimulus: as in getting scripters to write efficient scripts? impossible project :P

[3:40] Babbage Linden: as many of you said, it would be mean to enforce script limits at the same time as requiring lots of scripts to be used for trivial applications

[3:40] Morgaine Dinova: Well O(1) arrays would be a good start for efficient scripting that doesn't need lists :-)

[3:40] Han Sontse: well having more information about the implementation helps... rather than trying to dertermine it emperially

[3:40] Babbage Linden: at the moment I'm leaning towards wanting to implement llGetLinkPrimitiveParams

[3:41] JB Hancroft: ++Han

[3:41] Babbage Linden: as that's the most general solution

[3:41] Babbage Linden: which seems to make most of the reasons to have 1 script per prim go away

[3:42] Babbage Linden: although I really don't like our library functions that take lists of instructions to carry out

[3:42] Han Sontse: thats a good start, only if the delay goes away

[3:42] Babbage Linden: llDoSomeThings(list thingstodo)

[3:42] Liandra Ceawlin: ( Silly openal crashes. D: )

[3:42] Sheryl Mimulus: just daydreaming, but my personal wish list is a 0.0 delay llSetLinkPrimitiveParams and a llSetLinkText function

[3:43] JB Hancroft: wb Liandra

[3:43] Liandra Ceawlin: Sheryl ++

[3:43] Babbage Linden: we have a staticly typed language that supports multiple function arity, so I think we should use it

[3:43] Imaze Rhiano: Sheryl++

[3:43] Babbage Linden: which would suggest an llSetLinkText() llSetLinkScale() family of functions

[3:43] Babbage Linden: with getters

[3:43] Kaluura Boa: You won't be able to avoid it forever...

[3:43] Babbage Linden: so, I'm still mulling it over and would like to know your thoughts

[3:44] Han Sontse: hmm more events?

[3:44] Han Sontse: I don't like polling for stuff

[3:44] Imaze Rhiano: problem is that you have different kind primitives - but no support for objects - so you would need to have different functions for all of those obejct types

[3:44] Sheryl Mimulus: anything that allows us to synchronously update child prims is good :)

[3:44] Kaluura Boa: Yeah... An agen_info() event

[3:44] Imaze Rhiano: ... primitive types...

[3:44] Kaluura Boa: agent*

[3:45] Babbage Linden: right

[3:45] lonetorus Habilis: andrew touched on this, and said that there was no point in keeping delays for functions that dont acess outside resources, something about them already being managed by mono

[3:45] Liandra Ceawlin: I don't think removing the delay from llSetLinkPrimitiveParams entirely would cause any griefery. If a bad object wanted to spam the clients connection with a lot of prim param changes, they could still just use a ton of extra scripts.....

[3:45] Liandra Ceawlin: *client's

[3:45] Babbage Linden: i said that last week lonetorus ;-)

[3:45] Babbage Linden: i don't intend to add delays to any new functions

[3:45] lonetorus Habilis: mmh, ah well, you both said it then

[3:45] Babbage Linden: and would like to eventually have a way to have scripts turn off delays for existing functions

[3:46] Babbage Linden: functions that add load to external resources should be throttled

[3:46] Liandra Ceawlin: It would be really easy to just add a new version of llSetLinkPP with a new name, with no delay, and keep the old one around for compatibility, right? >_> Pweease? Lol.

[3:46] lonetorus Habilis: but i like that, more than one linden saying the same thing

[3:46] Babbage Linden: in the same way that llHttpRequest works

[3:46] Babbage Linden: we could add NoDelay versions of functions, but it's pretty horrible

[3:47] Liandra Ceawlin: Ohes. :<

[3:47] Babbage Linden: in C# you could use namespaces

[3:47] Liandra Ceawlin: Not a matter of just wrapping something with a flag that tells it whether to delay or not, huh? :<

[3:47] Imaze Rhiano: maybe compile option - "no delays"?

[3:47] Babbage Linden: have a LindenLab.SecondLife.Compatibility.Library

[3:47] Patnad Babii: namespace LSLV2 ^^

[3:47] Babbage Linden: and a LindenLab.SecondLife.Library

[3:47] Babbage Linden: the former just wrapping the latter and adding delays

[3:48] Babbage Linden: for people who like them, or rely on them to avoid race conditions

[3:48] Han Sontse: existing scripts aren't going to be recompiled.... so why make the distiction?

[3:48] lonetorus Habilis: and protecting exisitng (unsupported) content

[3:49] lonetorus Habilis: ah, good point han

[3:49] Babbage Linden: Han, we've tried to avoid silently changing behaviour

[3:49] Sheryl Mimulus: if there's a delay, then I'm afraid I'll still be using 1 prim per child script in most of my products as the changes to each prim needs to happen near-simultaneously.

[3:49] Babbage Linden: so, if you recompile a script having made no changes it works in the same way

[3:49] Han Sontse: Ah I see your point

[3:49] Babbage Linden: or gives you a compile error

[3:49] Babbage Linden: rather than compiling but having different behaviour

[3:49] Babbage Linden: adding NoDelay versions works

[3:50] Han Sontse: or just a flag? add a flag and delays go away?

[3:50] Han Sontse: like a pragma

[3:50] lonetorus Habilis: sounds as the quickets way (NoDelay)

[3:50] Babbage Linden: but it's really working around LSL not having support for namespaces or multiple libraries

[3:50] Patnad Babii: maybe it can be added in future updates?

[3:51] Babbage Linden: so, ok, interesting feedback, we need no delay functions (or a way of specifying no delays) as well as llGetLinkedPrimitiveParams

[3:51] Patnad Babii: and set a default namespace with script with no namespace

[3:51] Liandra Ceawlin: Very much so. And adding something the setlinkprimparams to set text would rawk too.

[3:51] Liandra Ceawlin: *to

[3:52] Babbage Linden: and that horrible as it is, the list style of arguments makes sense here to work around different prim types with different state

[3:52] Babbage Linden: (really we should have an OO library that exposes the differences via types and visitors, but you can all add that later...)

[3:52] Gunter Vandyke: what about llSetLinkScriptState ??

[3:52] Imaze Rhiano: Could you also remove disntance limitiations from llSetPos same time? - those warppos and jumppos are ebil hacks...

[3:52] Han Sontse: I'd like to see more methods than lists ㋡

[3:53] Babbage Linden: I'm not aiming to remove the need for all hacks right now

[3:53] Babbage Linden: (that will take a while)

[3:53] Babbage Linden: but I do want to minimise the number of scripts required to do a task

[3:53] JB Hancroft notes that the woman dressed in latex and wearing a posture collar is complaining about "ebil"

[3:53] Babbage Linden: so, in conjunction with script limits we have a way to make SL more efficient

[3:54] Babbage Linden: and make lag go away

[3:54] Liandra Ceawlin: I'd bet you this week's pay that a 0 delay setlinkprimparams would make 99% of the multiple scripts hacks go away. <_<

[3:54] Liandra Ceawlin: *90%, mistype. >_>

[3:54] lonetorus Habilis: yes, having to dole out tasks to slave scripts to work around delays is a nasty workaround

[3:54] Babbage Linden: (and make it easier to develop too, juggling a bazillion scripts in many prims is pretty horrid)

[3:54] Babbage Linden: right

[3:54] JB Hancroft sighs... absolutely

[3:55] Han Sontse: it looked good on paper but script engineers just found lag++ ways aroudn it

[3:55] Babbage Linden: ok, i'll think about this

[3:55] Babbage Linden: it was a horrible system that was never going to work

[3:55] Liandra Ceawlin: ( And I'll not withdraw any linden dollars this week, just in case. XD )

[3:55] Babbage Linden: i'm glad we're working towards something better

[3:55] Babbage Linden: but doing it in a way that doesn't break stuff is going to take some cunning

[3:55] Han Sontse: yeah

[3:56] Liandra Ceawlin: Nothing wrong with some low cunning! It worked in Zork. :P

[3:56] Babbage Linden: i'll try to think about a way to turn off delays that works well for C# and LSL

[3:56] Han Sontse: lol

[3:56] Patnad Babii: is it that bad that content breaks i mean it could save you a whole lot of time..

[3:56] lonetorus Habilis is ecstatic about all this news

[3:56] JB Hancroft: Is the direction toward CoreCLR something that will be visible to scripters? How much would it help for us to know that area well?

[3:56] Xugu Madison: If it helps clear through a lot of the need for old scripts to work, I'll donate some of my stuff to the library. So you'd have reference working versions for a lot of the core things people want (doors, rezzers, etc.)

[3:56] Babbage Linden: it could be that the NoDelay postfix is actually the easiest and cleanest way to do it in LSL, but I don't want to expose that to C'

[3:56] Babbage Linden: C# even

[3:56] Liandra Ceawlin: I think an API call to turn off delays would work just dandy, and not break any existing content.

[3:56] Han Sontse: content breaking is bad..... but maybe that contraint is over rated?

[3:57] JB Hancroft: llCaveatEmptor()

[3:57] Han Sontse: Si

[3:57] Babbage Linden: Han, I would agree if we had lots of information about how much content we might break

[3:57] Babbage Linden: but we don't

[3:57] Liandra Ceawlin: I mean, hacky sure, but it would tide us over very well until something more proper can be put together, mebbe? :o

[3:58] Babbage Linden: if it turns out that the 100 most popular scripted objects all have subtle race conditions that cause people to lose money when we remove delays, that would be bad

[3:58] Han Sontse: that makes no sense.... as you can run any content

[3:58] Morgaine Dinova: The rule should be not to break content **when it's avoidable**. Can't be using the "don't break" rule if it impedes SL progress, that would be terminal for SL's future.

[3:58] Babbage Linden: yes, but we don't know if it's working Han

[3:58] Babbage Linden: (most scripts don't come with unit tests)

[3:58] Babbage Linden: ;-)

[3:58] Han Sontse: hmmm

[3:58] JB Hancroft: but that's up to the vendor/maker to test, right?

[3:59] Liandra Ceawlin: Yea but... If it was an api call to turn off the delays, it would only be going into new content, and all the old stuff would not change a bit. :o

[3:59] Babbage Linden: so, the policy we've been trying to follow since Mono

[3:59] Imaze Rhiano: ... so how are memory limitis coming together?

[3:59] Babbage Linden: (which I think has been working well)

[3:59] Xugu Madison: and talking of memory limits, how's memory usage reporting coming?

[3:59] Babbage Linden: is to keep stuff working, but provide new shiny for people to try and use if they want to

[3:59] Babbage Linden: opt in to new functionality

[3:59] Han Sontse: agreed if there are ways to signal new abilites in an opt-in fasion that would be best

[3:59] Babbage Linden: so, opting in to 0 delays would be the way to go

[4:00] Patnad Babii: so basicly this mean dont change the actual functions :/

[4:00] Babbage Linden: and then when we introduce script limits people may go looking for the more efficient HUDs or hair that don't eat up their entire quota ;-)

[4:00] Han Sontse: well gradually deperciating and adding can help

[4:00] Liandra Ceawlin: llSetScriptDelay( FALSE ); :P

[4:01] Han Sontse: like llBase64New()

[4:01] Babbage Linden: we might be able to make it a compile time option

[4:01] Han Sontse: or whatever it was called

[4:01] Xugu Madison: llSetLibraryVersion()?

[4:01] Han Sontse: ooof

[4:01] Babbage Linden: if nodelay was specified it would just point the function calls at the no delay versions

[4:01] Imaze Rhiano: how about some new compile option instead? that would allow programmer to choose different version - you could use it later on to add more versions

[4:01] Babbage Linden: which would be closer to the namespace version

[4:02] Imaze Rhiano thinks that babbie just did read her mind...

[4:02] Han Sontse: some cruft is ok... but I don't want to have to pre-configure the environment like a microcontroller o.0

[4:02] Babbage Linden: some out of band information that tells the library awareness challenged LSL that it needs to use a different namespace

[4:02] Patnad Babii: yeah maybe a checkbox at bottom of the editor to swtich to the lsl2.0 library ot so

[4:02] Babbage Linden: even easier if we just made it LSL on mono specific

[4:03] Xugu Madison: I think we need a better long term solution to LSL function changes, and specifying the LSL version it's designed for would be a good idea... a drop-down box not a checkbox, IMHO

[4:03] Babbage Linden: as then we can just use versioned libraries...

[4:03] Xugu Madison: For when we have LSL 2.1, 2.2.1, 2.3, 3.0......

[4:03] Imaze Rhiano: Better Patnad - drop down list that allow you to choose version

[4:03] Babbage Linden: we have that functionality with LSL on Mono

[4:03] Babbage Linden: but it's a pain with Plain Old LSL

[4:03] Han Sontse: always default to latest -1

[4:03] JB Hancroft: hmmm... but then you might transparently enable no delays in mono content, and have race conditions (although the mono content is certainly newer...)

[4:03] Babbage Linden: hence the New postfix

[4:04] Babbage Linden: which sucks

[4:04] Imaze Rhiano: just ignroe old LSL

[4:04] Babbage Linden: no, all existing scripts would link against the LSL library version 1.0

[4:04] Babbage Linden: but there is also an LSL library version 2.0 in the GAC

[4:04] JB Hancroft: ah, ok

[4:04] Han Sontse: yeah makes sense

[4:04] Imaze Rhiano: old LSL v1.0 - Mono LSL v2.0 - Mono LSL "no delays" v2.1

[4:04] Babbage Linden: we just tell new scripts to compile against those

[4:04] Babbage Linden: if it's specified

[4:04] Han Sontse: well if someone didn't get the memo

[4:05] Han Sontse: but that is a dox issue

[4:05] Babbage Linden: and make the new library an opt in

[4:05] JB Hancroft: "don't use that checkbox unless you know what it means!" :)

[4:05] Babbage Linden: we need a drop down for targets in the viewer anyway

[4:05] Han Sontse: good idea

[4:06] Babbage Linden: Plain Old LSL, LSL on Mono, LSL on Mono No Delays, C#...

[4:06] JB Hancroft: would there be a need for a means for a script to query it's own compile status... ? just wondering...

[4:06] Patnad Babii: i like the idea with the namespace.. maybe that drop down box could set a template for the script, like C# will need //c# at the top right?

[4:06] Han Sontse: and a nice warning, "if you don't know what your doing don't!"

[4:06] Babbage Linden: then in the future Python, Ruby, Haskell, Boo.... ;-)

[4:06] JB Hancroft: woo hoo!

[4:06] Becky Pippen: Yay!

[4:06] Kaluura Boa: Wow!

[4:06] Babbage Linden: C# is a nasty hack

[4:06] Liandra Ceawlin: Java! <3 Lol.

[4:06] JB Hancroft: shhh ;)

[4:06] Liandra Ceawlin: *ducks*

[4:07] Babbage Linden: I don't really like //C#

[4:07] Xugu Madison: It's okay Liandra, I like Java too

[4:07] Han Sontse: *thorws coffee grounds at Lindara

[4:07] Liandra Ceawlin: Doh. :<

[4:07] JB Hancroft: Why not, Babbage?

[4:07] Babbage Linden: it's kind of like specifying interpreters in sh

[4:07] Babbage Linden: but in this case we're specifying compilers

[4:08] Babbage Linden: or targets

[4:08] Han Sontse: too many VMs and the host gets bloated...

[4:08] Patnad Babii: thats why we need that dropdown menu then, thats what will specify the language

[4:08] Babbage Linden: yes, exactly

[4:08] Babbage Linden: we already have a target parameter to the compilation service

[4:08] Babbage Linden: you should be telling the compilation service what to do

[4:08] Liandra Ceawlin: I have a totally unrelated question if you have time afterwards, though it will probably cause more shoes to be thrown at me, lol.

[4:08] Patnad Babii: awesome :)

[4:09] Babbage Linden: and telling it in the source code is mixing the message with the envelope ;-)

[4:09] Sheryl Mimulus: no functional languages? *poutZ*

[4:09] Babbage Linden: i'd like to keep them separate

[4:09] Babbage Linden: Haskell is fairly functional

[4:09] Han Sontse: lol

[4:09] JB Hancroft passes Sheryl his old FORTH manual

[4:09] Sheryl Mimulus: bah, I hate haskell lol

[4:09] Babbage Linden: although F# may be easier first

[4:09] Han Sontse: >_<

[4:09] Xugu Madison: woohoo F#!

[4:09] Babbage Linden: anyway, this is speculative

[4:09] Babbage Linden: the only thing we have planned at the moment is C#

[4:10] JB Hancroft: Any updates on the timeline for that?

[4:10] Babbage Linden: but, those plans are building up steam, which is good

[4:10] Imaze Rhiano: .... how are memory limits coming together?

[4:10] Liandra Ceawlin: Y'all ever think about switching over to git? With emerald development, it would be awesome to just be able to rebase off the LL master tree when there's a new upstream source release. >_>

[4:10] JB Hancroft notes that LL embraces Steampunk

[4:10] Babbage Linden: imaze, we are getting the UI team together for script limits

[4:10] Liandra Ceawlin ducks again. <_<

[4:10] Han Sontse: I have an issue with the whole multiple language issue.... for what purpose? There is no expectation of portablity between platforms. Why muddy the waters?

[4:10] Xugu Madison: Babbage, when you're hiring, try to get another poor volunteer from the scripting team to come do OH with us so we can give them the other hour of questions you don't have time for? :)

[4:10] Babbage Linden: they're busy with ....other viewer work at the moment

[4:11] Babbage Linden: but will be building the script limits UI at the end of the year

[4:11] Imaze Rhiano: yay

[4:11] Xugu Madison: Han; because it's easy once we have C#, pretty much, and other languages add flexibility

[4:11] Aimee Trescothick: http://bitbucket.org/lindenlab/snowglobe/ Liandra

[4:11] Babbage Linden: we're still looking at the numbers

[4:12] Babbage Linden: but those plans are coming together too

[4:12] Aimee Trescothick: Hg rather than Git

[4:12] Liandra Ceawlin: Hmmmm, I bet if I could get Greg to switch over to git, we could still rebase off it some way. <_< I need to do some reading I reckon. >_>

[4:12] Babbage Linden: so, that's about it

[4:13] Babbage Linden: i have another interview i need to run to now

[4:13] Xugu Madison: Good luck!

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

[4:13] Imaze Rhiano: Thanks Babbie

[4:13] Liandra Ceawlin: Thanks for your time! ^_^

[4:13] Xugu Madison: Thanks for hosting Babbage!

[4:13] Jonit Ivory: Thanks Babbage

[4:13] Han Sontse: Thanks ㋡

[4:13] Sheryl Mimulus: thanks babbage :)

[4:13] Gunter Vandyke: thanks Babbage

[4:13] Patnad Babii: thanks i must say its the best OH i had in a while ^^

[4:13] JB Hancroft: excellent... thanks, Babbage :)

[4:13] Kaluura Boa: No picks and forks...

[4:13] Aimee Trescothick: https://wiki.secondlife.com/wiki/Mercurial_repositories

[4:14] Xugu Madison: Anyone got a transcript for those of us who turned up halfway through?

[4:14] Babbage Linden: please keep sending me sim freeze inducing objects for testing

[4:14] Babbage Linden: and reasons why you have to use many scripts

[4:14] Babbage Linden: and

[4:14] Babbage Linden: see you in 2 weeks!

[4:14] JB Hancroft: tc :)

[4:14] Liandra Ceawlin: Have a groovy day! ^_^

[4:14] Becky Pippen: Thanks Babbage!

[4:14] Xugu Madison: Seeya Babbage!

[4:15] Liandra Ceawlin: Mew. :<
Retrieved from "https://wiki.secondlife.com/w/index.php?title=User:Babbage_Linden/Office_Hours/2009_11_04&oldid=644063"