User:Babbage Linden/Office Hours/2010 02 03

Transcript of Babbage Linden's office hours:

[2:59]	Sebastean Steamweaver:	It's a babbage!
[2:59]	CPU Core:	hi babbage
[3:00]	Babbage Linden:	good morning!
[3:00]	Babbage Linden:	how is everyone!
[3:00]	Babbage Linden:	?
[3:00]	Nock Forager:	morning!
[3:00]	Sebastean Steamweaver:	Morning
[3:00]	Sebastean Steamweaver:	Doing all right
[3:00]	Becky Pippen:	Hi Mr. B. and all
[3:00]	Ardy Lay:	5AM, having tea.
[3:00]	Imaze Rhiano:	good day Babbie
[3:01]	Babbage Linden:	thanks to everyone who has had a look at the LSL HMAC-SHA1 code
[3:01]	Babbage Linden:	especially to Cale and Latif who got solutions that got the right results for the examples
[3:02]	Babbage Linden:	unfortunately they don't seem to work properly for OAuth data
[3:02]	Imaze Rhiano:	:(
[3:02]	Babbage Linden:	I've added some notes here: http://lsl.pastebin.com/m95bc82
[3:03]	Babbage Linden:	the LSL implementation needs to match the .NET implementation here: http://buchananweb.co.uk/security01.aspx
[3:03]	Babbage Linden:	when using OAuth data which can be generated here: http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signing-requests/
[3:03]	Babbage Linden:	I have a finished and working OAuth library implemented using the C# prototype, which uses the same code as http://buchananweb.co.uk/security01.aspx
[3:04]	Babbage Linden:	I've also ported the C# library to LSL
[3:04]	Babbage Linden:	so, as soon as we can get an HMAC-SHA1 that matches http://buchananweb.co.uk/security01.aspx we'll have a working LSL OAuth library
[3:05]	Babbage Linden:	the C# implementation did a great job of demonstrating the value of C# scripting at the Linden offsite last week
[3:05]	Imaze Rhiano:	Are Cale's and Latif's code available somewhere?
[3:05]	Object: Hello, Avatar!
[3:05]	Babbage Linden:	people were so excited they want an LSL implementation so they don't have to wait for C# ;-)
[3:06]	Babbage Linden:	Latif's code is here: http://lsl.pastebin.com/f6383724c
[3:07]	Babbage Linden:	as a number of people pointed out, the initial problem was that I was using llSHA1String which doesn't work as the data is a unicode string, not a binary array
[3:07]	Babbage Linden:	but there seems to be another problem somewhere
[3:08]	Babbage Linden:	Latif's solution uses Strife Onizuka's LSL SHA1 implementation from the wiki
[3:08]	Babbage Linden:	Cale wrote an alternative SHA1 implementation, which is faster
[3:08]	Babbage Linden:	I'll ask him to put his code online
[3:09]	Babbage Linden:	it would be great if we can work together to get this working in LSL
[3:09]	Babbage Linden:	the C# implementation is very effective
[3:09]	Babbage Linden:	I've been having lots of people asking what I'm up to when updates appear on my twitter stream
[3:10]	Babbage Linden:	it will be a very effective way of promoting SL experiences
[3:10]	Babbage Linden:	it's also been really useful implementing a reasonably complex library in both C# and LSL in Second Life
[3:10]	Babbage Linden:	it's exposed a number of bugs and limitations with the C# prototype
[3:11]	Babbage Linden:	but also exposed the limitations of LSL when working with the web
[3:11]	Babbage Linden:	as we're discovering, cryptography without byte arrays is hard
[3:11]	Imaze Rhiano:	:P
[3:12]	Babbage Linden:	and even when you have byte arrays, manually implementing cryptography is hard
[3:12]	Babbage Linden:	being able to search for C# HMAC and get a 10 line example I can use in 5 minutes is much nicer :-D
[3:12]	Xugu Madison:	Bah. Try cryptanalysis!
[3:12]	Babbage Linden:	C# is going to make SL so much more productive
[3:12]	Xugu Madison:	Yes!
[3:13]	Babbage Linden:	it was a useful excercise to see where we need to improve the current API too
[3:13]	Babbage Linden:	for example, currently the ll* methods take ArrayLists as parameters where lists are used in LSL
[3:14]	Babbage Linden:	which means you need to do lots of new ArrayList(new object[]{HTTP_METHOD,"GET"}) style code
[3:14]	Babbage Linden:	which is pretty horrible
[3:14]	Babbage Linden:	we can improve it to make the ll* functions take object arrays
[3:15]	Christine Milneaux:	Babbage, what are the 5 percent of SL areas that you are targeting with your new script memory limits? I build holodecks.... with these new script limits in place, will I (And my costomers!) still be able to drop a holodeck in a sandbox and expect it to work, what with memory being limited?
[3:15]	Babbage Linden:	but, I would still like to have some kind of object[] ParseList("["foo", "bar", "baz", 1, 2, 3, <1,2,3>]") style helper
[3:15]	Gypsy Paz:	yes! I'd like to hear more details about memory limits too
[3:16]	Babbage Linden:	and we should also add .Parse("<1,2,3>") methods to vectors and quaternions in C# too
[3:16]	Babbage Linden:	LSL is much terser when using lots of literals atm
[3:16]	Babbage Linden:	(which it turns out you do a lot of in practice)
[3:16]	Babbage Linden:	but, on the other hand, having arrays and switch statements makes C# a lot nicer to use
[3:17]	Babbage Linden:	so, at the moment it's swings and roundabouts, but there are things we can do to make C# nicer in SL yet
[3:17]	Xugu Madison:	and complex types!
[3:17]	Babbage Linden:	rigth
[3:17]	Asuka Chun:	user defined types too?
[3:17]	Babbage Linden:	being able to build an LRU access token cache out of a System.Collections.Hashtable in the C# version was nice
[3:17]	Xugu Madison:	having to use 2-3 lists to describe a list of associated pieces of data, is crazy...
[3:18]	Babbage Linden:	much nicer than using a strided list in the LSL version...
[3:18]	Ceawlin Steamweaver:	Strided lists are ebil, especially with the pass-by-value semantic. X_x
[3:18]	Babbage Linden:	so, it was a super useful exercise that got lots of Lindens excited about C#
[3:19]	Xugu Madison:	Any sort of timeline for C# on beta grid?
[3:19]	Babbage Linden:	allowed me to learn a lot about the C# interface
[3:19]	Babbage Linden:	and may yet produce an LSL OAuth library that we can all use to promote SL objects and experiences on the social web...
[3:19]	Babbage Linden:	the time line for C# is Q3 beta on aditi
[3:19]	Xugu Madison:	long term, I'd still like to see a more object-orientated API. So I can write " this.link[1].setTexture(....)" for example
[3:20]	Ceawlin Steamweaver:	Speaking of timelines, I have the usual annoying recurring question about the ETA of efficient scripting API on aditi, that I am supposed to keep asking you about every week, if you don't mind touching on that briefly at some point. I apologize for bugging you about it so much, lol. ;P
[3:20]	Babbage Linden:	Xugu, long term I'd like to make it possible for you to build a more object oriented API with proper support for script libraries :-D
[3:20]	Xugu Madison:	Q3. Oh dear. I'm going to have to just sleep for 6 months then...
[3:21]	Babbage Linden:	no problem, the code freeze for 1.38 is still mid Feb
[3:21]	Ceawlin Steamweaver:	thankies
[3:21]	Babbage Linden:	efficient scripts is in QA and on track for that release
[3:21]	Ceawlin Steamweaver:	\o/
[3:21]	Xugu Madison:	Great!
[3:21]	Xugu Madison:	Is there a changelist for efficient scripts?
[3:21]	Liisa Runo:	❤
[3:21]	Babbage Linden:	so that will give you something to play with Xugu
[3:21]	Xugu Madison grins
[3:21]	Babbage Linden:	and you can always try making LSL HMAC-SHA1 work in the meantime ;-)
[3:21]	Kaluura Boa:	Will there be a new RC?
[3:21]	Babbage Linden:	1.38 is a server release
[3:22]	Kaluura Boa:	Client RC, I mean
[3:22]	Babbage Linden:	but it's adding the final server support for the next viewer release
[3:22]	Kaluura Boa:	To be able to use the new functions
[3:22]	Babbage Linden:	which will be out soon
[3:22]	Babbage Linden:	we're making some final changes for Script Limits support
[3:22]	Imaze Rhiano:	aww... still no announcement about new viewers features :(
[3:23]	Babbage Linden:	LSL scripts will be using 16KB of reserved memory, you will be pleased to know
[3:23]	Babbage Linden:	we're still trying to work out how to display Mono bytecode sharing
[3:23]	Babbage Linden:	my initial thoughts were to have the first script include the bytecode cost
[3:23]	Babbage Linden:	and subsequent copies have that discounted
[3:23]	Ceawlin Steamweaver:	Have y'all gotten any ideas if any kind of rough guesstimation on what the limits will likely be?
[3:24]	Babbage Linden:	so, if you have a Mono script with 4KB bytecode
[3:24]	Babbage Linden:	the first script would reserve 64KB from the pool
[3:24]	Babbage Linden:	subsequent copies would reserve 60KB
[3:24]	Babbage Linden:	but, kelly pointed out that if you showed that on the script limits UI it may be confusing
[3:24]	Babbage Linden:	because if you return the first script
[3:25]	Babbage Linden:	the second script usage would go up to 64KB
[3:25]	Imaze Rhiano:	I have asked couple times how to do Mono's bytecode sharing - I have just simple answered "Compile your script once - then copy compiled script to other places" - woudl be great to see script's assembly - or - somekind visual clue that scripts are sharing same assembly
[3:25]	Babbage Linden:	and it would feel like whack-a-mole
[3:25]	Babbage Linden:	do you think that would be a problem, or not?
[3:25]	Eddi Decosta:	heya morning ㋡
[3:25]	Xugu Madison:	I think it would seem a bit weird, but people just need to learn that's how it works...
[3:25]	Babbage Linden:	would it be better to have both scripts reserve 62KB?
[3:26]	Babbage Linden:	xugu, that's what I think too
[3:26]	Christine Milneaux:	What is the 5% of land that will be targeted? And, yes, it would
[3:26]	Babbage Linden:	but, I'm a software engineer and not a UI expert ;-)
[3:26]	Babbage Linden:	if you can have a think about how to present bytecode sharing in a non-confusing way that would be great
[3:26]	Xugu Madison:	Christine, I'm not sure 5% is a specific figure (is it?), and the target is land using the most memory AFAIK.
[3:27]	Babbage Linden:	at the moment we're probably going to leave it out of 1.38
[3:27]	Babbage Linden:	and hopefully put it in when we get to big scripts
[3:27]	Xugu Madison:	Babbage, if you show only bytecode sharing on the same parcel, that should at least remove weirdness where someone returns something on the other side of the region and suddenly your usage goes up
[3:27]	Gypsy Paz:	"big scripts"?
[3:27]	Vextra Messing:	can it somehow show the amount shared, like in brackets afterwards? like 60 (4) in your example?
[3:28]	Babbage Linden:	xugu, possibly
[3:28]	Babbage Linden:	gypsy, big scripts is the project where we let mono scripts set the amount of memory they want to reserve
[3:28]	Ceawlin Steamweaver:	Want.... :d Lol.
[3:28]	Gypsy Paz:	that sounds nice
[3:28]	Babbage Linden:	so, if you have a door, you might make it reserve 4KB
[3:28]	Imaze Rhiano:	ya... might be best to have two numbers for mono scripts - amount of used by script - and - amount of shared memory used by scripts
[3:28]	Babbage Linden:	which would make it more efficient than an LSL door script
[3:29]	Babbage Linden:	if you want to parse XML you might reserve 1MB
[3:29]	Babbage Linden:	unlike LSL, there is no reason that Mono scripts should be a set size
[3:29]	Babbage Linden:	(and having to chop scripts up when you need more than 16KB is horrible atm...)
[3:29]	Sebastean Steamweaver:	Very
[3:29]	Christine Milneaux:	Eek.... will LSL code still work when this happens?
[3:29]	Sebastean Steamweaver:	Very very very
[3:30]	Gypsy Paz:	so like we'll have llSetMemoryReserve() function for the state entry or something? or more like a setting in the script editor?
[3:30]	Babbage Linden:	christine, LSL scripts running on the plain old VM will always use 16KB
[3:30]	Christine Milneaux:	O_O So I can't have more than one per meter of land?
[3:30]	Babbage Linden:	LSL scripts running on Mono will be able to call llSetReservedMemory or something similar
[3:30]	Ceawlin Steamweaver:	I am really hoping that the script will be able to adjust it's own reserve memory programatically. :o
[3:30]	Xugu Madison:	(Bloo katana kitty on a cog looks like a dangerous combination...)
[3:31]	Babbage Linden:	once Mono scripts are using different amounts of memory, factoring in bytecode sharing will be less weird I think
[3:31]	Gypsy Paz:	Im very much liking what Im hearing about the memory limits here ㋡
[3:31]	Babbage Linden:	(as script memory usage may be going up and down any way)
[3:31]	Xugu Madison:	Pondering memory usage, any concrete plans for letting us move messages into client-side assets (so that error messages don't eat script memory, and different languages are easy to do)?
[3:32]	Gypsy Paz:	the scripts will be able to exceed the reserved memory though, right? like if you reserver 4k, and use 12k, it wont stack heap, but just not be as effieint?
[3:32]	Eddi Decosta:	Babbage, i have a question about hud using in im , if you can ressure me on this ㋡
[3:32]	Babbage Linden:	xugu, hopefully we'll get to client side scripts for that
[3:32]	Babbage Linden:	or you will be able to pull error pages off the web with shared media...
[3:32]	Ceawlin Steamweaver wants to make floaters from scripts. :d
[3:33]	Xugu Madison:	so, client-side scripts... before, or after the heat death of the universe? :)
[3:33]	Kaluura Boa:	Me too
[3:33]	Babbage Linden:	ceawlin that is the end goal of the Firefly project that Q is working on
[3:33]	Sebastean Steamweaver:	Or we'll be able to send messages to the user's client with server side scripts >:)
[3:33]	Ceawlin Steamweaver:	And have UI callbacks into LSL. :d
[3:33]	Ceawlin Steamweaver:	Oooo
[3:33]	Morgaine Dinova:	So client-side scripts are now on the timeline?
[3:33]	Xugu Madison:	floaters? Firefly?
[3:33]	Ceawlin Steamweaver:	I'll have to invade Q's OO and get the skinny on that. O_O
[3:33]	Sebastean Steamweaver:	Or if pigs fly, generate text on a prim face ;)
[3:33]	Babbage Linden:	I'm hoping before, as having to do computations without increasing entropy is going to make client side scripts hard to implement
[3:33]	Saijanai Kuhn:	22 avatars. Why is this sim so laggy
[3:34]	Xugu Madison blames the cogs
[3:34]	Christine Milneaux:	Lag is a part of life, my friend
[3:34]	Imaze Rhiano:	:P
[3:34]	Eddi Decosta:	yeah Saij, i notice this with my 4go of memory :p
[3:35]	Sebastean Steamweaver:	Suddenly Silence
[3:35]	Xugu Madison is on a laptop. Katana kitty goes around and around, but mostly his client doesn't do motion anyway, so no change....
[3:35]	Morgaine Dinova:	Waiting for Babbage to confirm about client-side scripting
[3:35]	Ceawlin Steamweaver:	If we souped up these cogs, we could use Morg for a blender. :o
[3:35]	Saijanai Kuhn:	what would "client-side" scripting mean in this context?
[3:35]	Babbage Linden:	I'm not the press department, so you won't get any announcements from me
[3:35]	Christine Milneaux:	So.... for the simple-minded woman...... WILL I be able to plop an LSL-style holodeck in a sandbox and expect it to work?
[3:35]	Babbage Linden:	but Q and the boston firefly team have a plan that is working towards client side scripts
[3:36]	Xugu Madison:	Saijanai; having objects in SL be able to move a script asset to the remote client, where it runs in a sandbox, AFAIK
[3:36]	Sebastean Steamweaver:	The bloo-bladed kitty goes round and round....
[3:36]	Babbage Linden:	the goal would be to have scripts marked as client side scripts
[3:36]	Liisa Runo:	the holodeck will prolly work, but if it tries to rez a scene that has 800000 scripts it might fail
[3:36]	Babbage Linden:	which are downloaded and run in each client that sees the object
[3:36]	Babbage Linden:	the client side script would be able to build GUIs and interfaces
[3:37]	Saijanai Kuhn shrugs
[3:37]	Babbage Linden:	and hopefully also do client side prediction of object movement
[3:37]	Saijanai Kuhn:	seems there are easier ways to do that
[3:37]	Babbage Linden:	and would be able to communicate with the server side scripts
[3:37]	Xugu Madison:	Sai, oh?
[3:37]	Sebastean Steamweaver:	I was about to ask that.
[3:37]	Babbage Linden:	to build shared experiences
[3:37]	Christine Milneaux:	Thanks Liisa
[3:37]	Morgaine Dinova:	Babbage: The point is, lots of community groups are looking at scripting in the client. Your line "[3:32] Babbage Linden: xugu, hopefully we'll get to client side scripts for that" suggests that it's not just a resident wishlist thing, but that you see it as a target for work in LL. If it's an actual future project, then it undermines what the community is doing, unless it's an open project in Snowglobe.
[3:37]	Sebastean Steamweaver:	Heh, shared experiences. Sounds too much like Windlight :P
[3:38]	Ceawlin Steamweaver:	Ultimately, it would be really nice to be able to have a script rez an object and get some kind of reference to it to be able to manipulate it in various ways without having a script in it. I predict that will be about the only thing that efficient scripts API doesn't fix, as far as the tons of scripts everywhere problem...
[3:38]	Babbage Linden:	morgaine it is something that we're looking at and working towards at linden
[3:38]	Babbage Linden:	q is keeping an eye on the open source efforts too and we're discussing how they interact
[3:38]	Morgaine Dinova:	Babbage: according to M, this year begins "a new openness" .... is this scripting going to be done closed?
[3:39]	Babbage Linden:	for example the open source lltextbox extensions are not as complete and useful as the firefly plans
[3:39]	Babbage Linden:	but, they would undoubtedly be useful for script UI in the meantime
[3:39]	Kaluura Boa:	Sre!
[3:39]	Kaluura Boa:	Sure*
[3:40]	Sebastean Steamweaver:	They would be super in the UI - Emerald has had it implemented just fine for a while now.
[3:40]	Babbage Linden:	and if they are implemented in the same way as llDialog, the maintenance overhead won't be huge
[3:40]	Xugu Madison:	Q Linden is Wednesdays from 8am.... I suggest we go poke them about Firefly/client-side scripting?
[3:40]	Sebastean Steamweaver:	The only reason I can't use it in my own scripts for user UIs, is that it isn't in the official viewer yet.
[3:40]	Babbage Linden:	these are all the same issues that open source projects have
[3:40]	Saijanai Kuhn:	what is firefly?
[3:40]	Babbage Linden:	when different forks implement things in different ways
[3:40]	Babbage Linden:	i'm in favour of giving as much information as we can about pending up coming projects
[3:41]	Babbage Linden:	so avoid collisions with open source efforts as much as possible
[3:41]	Babbage Linden:	but, it's not always my call
[3:41]	Babbage Linden:	i've said lots about the scripting plans
[3:41]	Babbage Linden:	which will hopefully provide useful input for opensim and other open source development efforts
[3:42]	Morgaine Dinova:	It's not just because of collisions. It's because you would get a better design working WITH the community on it, instead of behind closed doors.
[3:42]	Babbage Linden:	to avoid incompatibilities and overlap and wasted effort and to come up with the best solutions
[3:42]	Morgaine Dinova:	It's an open source client after all. Working in secrecy on features for it is pretty .... <deleted>
[3:42]	Xugu Madison still thinks we need an office hour with the people who get to decide when we hear stuff...
[3:42]	Babbage Linden:	we've talked a lot about how to implement bytecode sharing accounting for example
[3:42]	Babbage Linden:	morgaine, i agree
[3:43]	Christine Milneaux:	Sorry, but I'm still not fully understanding... Under the new script limits, you can only have 1 LSL script per meter?
[3:43]	Babbage Linden:	no christine, you get N KB of memory per meter sq
[3:43]	Imaze Rhiano:	I really appreciate your openess Babbage, thank you! Unfortunately most of Lindens don't share same viewpoint anymore - it is impossible to get any information about viewer 2.0
[3:43]	Gypsy Paz:	Babbage, I've heard allot of people lately expresses concerns about the memorny limits breaking content, do you have any comments on that?
[3:43]	Liisa Runo:	when speaking about text-on-a-prim-face.. i must point out that 99% of the use will be similar to llSetText, so we need simple function for it. _NOT_ some media on a prim thing that slowly request the data from outside the script
[3:43]	Xugu Madison:	Christine, it sounds like you've got a very odd information source... where is this coming from?
[3:43]	Babbage Linden:	(we're still working on the final numbers)
[3:43]	Babbage Linden:	imaze, that's not my call
[3:44]	Christine Milneaux:	I'm getting it all from what's being said today and what's on the wiki
[3:44]	Babbage Linden:	(and I have to try to avoid getting in to trouble being too open here too)
[3:44]	Saijanai Kuhn:	Lisa why not just xml/html/svg on a prim using a note card (or 2) in the prim's inventory?
[3:44]	Babbage Linden:	for example, i'm glad I've spoken to you all openly about script limits
[3:44]	Babbage Linden:	but it caused a lot of panic and running around before christmas
[3:45]	Xugu Madison:	Christine, okay. Just there's a lot of rumours going around, and much of it isn't that concrete yet...
[3:45]	Babbage Linden:	that caused some heat for me in the lab around communication
[3:45]	Kaluura Boa:	Notecard? Bleh... We want dynamic text on a prim
[3:45]	Babbage Linden:	so, it's hard, but in general I try to be as open as I can
[3:45]	Gypsy Paz:	well, being able to talk about it more might help some of hte fears ㋡
[3:45]	Liisa Runo:	notecards are slow, and cant write to them, as i said, most of the use will be output generated by the script
[3:45]	Ceawlin Steamweaver:	I personally don't think memory limits will ahve a very adverse effect on anything. Imo it was crazy to not have a memory quota in from the beginning (no offense), and most things other than ridiculous script-in-every-prim maddness are probably using trivial amounts of memory and will work just fine...
[3:45]	Babbage Linden:	and I think as a company we're working on getting better with communication
[3:46]	Babbage Linden:	ceawlin, I agree
[3:46]	Babbage Linden:	per script limits were around before I turned up, unfortunately
[3:46]	Xugu Madison:	bit of a topic hop, but... how's HTTP textures (from LL, not from external sources) going?
[3:47]	Babbage Linden:	and, to be fair, some pretty amazing things have been built in SL despite the original script limit weirdness
[3:47]	Sebastean Steamweaver:	I'm hoping and praying taht the "efficient scripts" project comes through for the "many scripts" problem.
[3:47]	Saijanai Kuhn:	well, unless you establish a communications channel specifically for what shows on the prim, you're always going to run into the same bottlenecks
[3:47]	Gypsy Paz:	personally, I see what's been talked about here today being very good for new scripts that handle it properly, but can cause problems on some of the older scripts on land that just has too many scripts running
[3:47]	Sebastean Steamweaver:	Oy, pardon the typos.
[3:47]	Babbage Linden:	right, with script limits, efficient scripts and big scripts the memory model for scripts will be much better i think
[3:47]	Babbage Linden:	much less wasted resources
[3:47]	Babbage Linden:	and much more productive for scripting large projects
[3:48]	Xugu Madison is hoping for a "stable scripts" (error handling) project later on
[3:48]	Sebastean Steamweaver:	Babbage, Andrew metioned that you wre hoping to allow script versioning soon.
[3:48]	Sebastean Steamweaver:	Is there any timeframe on that?
[3:48]	Ceawlin Steamweaver:	Gypsy: I think that sometimes existing content has to be broken for the same of moving forward. Otherwise you have craziness in the same vein as the i386 still supporting the 8080 instruction set and other such cruft. >_>
[3:48]	Babbage Linden:	xugu, I hope that we can do that with exceptions
[3:48]	Ceawlin Steamweaver:	*sake
[3:48]	Gypsy Paz:	lol, you are right of course Ceawlin
[3:48]	Xugu Madison:	Yes!
[3:48]	Babbage Linden:	as it will allow us to add error returns to existing ll* functions without breaking their signatures
[3:49]	Babbage Linden:	C# scripts will be able to catch them
[3:49]	Babbage Linden:	LSL scripts will run as normal
[3:49]	Babbage Linden:	we'd just need a shim around the library calls for LSL scripts that consumed the exception and continued
[3:50]	Babbage Linden:	(or stored the error in a variable called by llGetLastError() or something)
[3:50]	Christine Milneaux:	Babbage, can I clear something up with you about script limits in Im?
[3:50]	Christine Milneaux:	Just some minute detail that everbody but me understnds =P
[3:51]	Babbage Linden:	sure, but I'd prefer to just talk in chat
[3:51]	Sebastean Steamweaver:	Babbage, is there a timeframe on when you would be able to enable versioning for scripts?
[3:51]	Babbage Linden:	other people might want to know
[3:51]	Babbage Linden:	so, the versioning andrew is refering to is library versioning
[3:51]	Sebastean Steamweaver:	Ah, go ahead Christine.
[3:51]	Babbage Linden:	which we already have for Mono scripts
[3:51]	Babbage Linden:	currently scripts compile against version 1.0 of LslLibrary.dll
[3:52]	Babbage Linden:	we can add a new version of that library to the GAC
[3:52]	Babbage Linden:	and have new scripts compile against the new version
[3:52]	Gypsy Paz:	GAC?
[3:52]	Babbage Linden:	or choose which version they compile against
[3:52]	AOS-HUD 3.5.184 [WEAR ME!]: - The scanner on steroids - [1]
[3:52]	Babbage Linden:	the Global Assembly Cache
[3:52]	Babbage Linden:	which is what .NET uses to avoid dll hell
[3:53]	Christine Milneaux:	OK, so, LSL scripts will take UP 16 kb of memory, which, I thought you used as an example for the amount of memory we have per meter... so one LSL script per meter?
[3:53]	Ceawlin Steamweaver:	Even if scripts are only given 256 megs per simulator, that's still what, 512k per sqm? That's 8 mono scripts per sqm. And I expect that would increase over time with moore's law...
[3:54]	Ceawlin Steamweaver:	That's still a lot of scripts, lol.
[3:54]	Xugu Madison:	Oh, yeah, how are the new class 6 sims coming? *duck*
[3:54]	Babbage Linden:	christine, we're going to set limits using KB per sq. m. and KB per avatar for attachments
[3:54]	Gypsy Paz:	is the scripts memory usage going to be in the region/estate for sim owners only? or will that info be more exposed?
[3:54]	Christine Milneaux:	And at this point, would things that require a lot of scripts, like holodecks, slave collars, the old stuff that might not be made with mono.... that's going to become either useless or obsolete or both?
[3:54]	Babbage Linden:	you can then choose whether to use 16KB LSL scripts or 64KB Mono scripts
[3:55]	Babbage Linden:	and, after big scripts, N KB Mono scripts
[3:55]	Babbage Linden:	we're still discussing what the actual limits will be
[3:55]	Vextra Messing:	I guess it may be unknown, but will C# be subject to limits in the same way as well?
[3:55]	Christine Milneaux:	Ohhhh, so LSL scripts and mono scripts have a st number of memory they use?
[3:56]	Babbage Linden:	but they are going to support 95+% of current usage
[3:56]	Christine Milneaux:	And LSL uses less memory than mono?
[3:56]	Babbage Linden:	christine, yes at the moment LSL scripts always reserve 16KB an Mono scripts always reserve 64KB
[3:56]	Sebastean Steamweaver:	No matter how much of that amount they actually use.
[3:56]	Imaze Rhiano:	Initially LSL uses less memory - until Mono is able to start allocating necessary memory
[3:57]	Gypsy Paz:	Christine, I suspect that if your scripts are not currently lagging your sim to a standstill, they will still work ok afterward
[3:57]	Babbage Linden:	we gave Mono scripts 64KB when we launched Mono as there were some corner cases when a 16KB LSL script needed 64KB of memory in Mono
[3:57]	Ceawlin Steamweaver:	Some things may become useless or obsolete or need fixed to be more efficient. But sticking with the old way just because it is already there would be akin to trying to ride a horse to work on the DC beltway. Gotta abandon the old ways to progress to new and better things. :P
[3:57]	Babbage Linden:	because we wanted people to always be able to convert to Mono we increased the Mono size
[3:57]	Sebastean Steamweaver:	It's like a glass with water. You ahve a 16oz glass, and you only fill it with 4oz of water but it still takes up the same amount of space in a fridge as a full glass.
[3:57]	Babbage Linden:	in most cases Mono scripts actually use less than 16KB of simulator memory
[3:57]	Christine Milneaux:	I see
[3:58]	Babbage Linden:	but they reserve 64KB to be safe
[3:58]	Babbage Linden:	when we have big scripts released you'll be able to say
[3:58]	Babbage Linden:	i know my script will never use more than 8KB, so that's what I'm going to reserve
[3:59]	Christine Milneaux:	So basically, I do not have t hire a team of scripters to redesign all my holodecks so they work with the limits? I can keep things as they are?
[3:59]	Babbage Linden:	or, I know google.com might give me 1MB of XML, so that's what I'm going to reserve
[3:59]	Sebastean Steamweaver:	Babbage, I have one more question before we leave, continuing on my previous line, if that's ok?
[3:59]	Babbage Linden:	no Christine, everything will continue to work
[3:59]	Babbage Linden:	although you might find you can tweak your holodecks to work in more places
[3:59]	Kaluura Boa:	95% of everything
[3:59]	Imaze Rhiano:	ya... somethings are definately going go stop working - that is whole point about limits - those somethings are lagging simulators so they are causing problems for pretty much everything. Point is just - find good limit (that is not yeet found) where those worst offenders stop working, but still most of other good working content is working.
[3:59]	Christine Milneaux:	ALRIGHT!! -happy holodeck seller is happy-
[4:00]	Babbage Linden:	yay!
[4:00]	Gypsy Paz:	what will happen when the scripts memory limit is exeeded? will they all just stop, or will it force the time diliation down to catch up or what?
[4:00]	Gypsy Paz:	㋡
[4:00]	Babbage Linden:	gypsy, when LSL scripts hit 16KB, they will stack-heap collision, there is nothing else they can do
[4:00]	Gypsy Paz:	right, I was talking about total sim memory limits of all scripts in the region
[4:01]	Babbage Linden:	when Mono scripts hit there limit (whatever they have reserved) we have 2 options: allow them to grow, or make them stack-heap collide
[4:01]	Babbage Linden:	I'm still not sure which is better
[4:01]	Babbage Linden:	as a land owner I want to be able to set up my parcel with scripts
[4:01]	Babbage Linden:	and know that they will all keep running
[4:01]	Babbage Linden:	but, if I leave 64KB free for emergencies
[4:02]	Babbage Linden:	should a script be able to use that extra 64KB instead of crashing?
[4:02]	Babbage Linden:	I'm not sure
[4:02]	Gypsy Paz:	well, the problem with stack heaps has always been, it stops the script cold, so if that happens in a no-mod object, than that object is pretty much permantly dead
[4:02]	Liisa Runo cam's around: lol, some people are bold, person with pay info is selling copybotted item, just 15ometers from a Linden office ^^
[4:02]	Ceawlin Steamweaver:	I think if you make the limits too soft, there will be weird interactions that will cause things to go wonky. >_>
[4:02]	Liisa Runo:	150*
[4:02]	Christine Milneaux runs up to babbage and hugs him
[4:02]	Sebastean Steamweaver:	I had mentioned a possible improvement on one of the "efficient scripts" functions being currently worked on, llSetLinkPrimitiveParamsFast, and Andrew mentioned that though it was too late to change, script versioning might enable development on it. Would that be something you would be interested in looking into, as part of the efficient scripts project?
[4:03]	Babbage Linden:	ceawlin, I tend to agree
[4:03]	Ceawlin Steamweaver:	I'd like to be able to get an exception or something when a script stack-heaps and be able to deallocate something if possible and continue though. <_<
[4:03]	Sebastean Steamweaver:	Well, I didn't actually intend to hit enter that soon, but oh well :P
[4:03]	Gypsy Paz:	lol, if you made limits to soft, everyone would ignore them, just look at what happened with homesteads ツ
[4:03]	Babbage Linden:	people are used to 6 prim objects
[4:03]	Babbage Linden:	but, 6 prim objects can rez extra prims...
[4:03]	Babbage Linden:	I think the default will be that there will be no automatic growth
[4:03]	Eddi Decosta:	Gypsy , i can take your smile? ㋡
[4:03]	Imaze Rhiano:	better just throw stack heap expection - like it is happening now - it is more deterministic
[4:04]	Gypsy Paz:	how do you think I got it Edidi ㋡
[4:04]	Babbage Linden:	but I would like to be able to let scripts query their usage, try to reserve more and then deal with the failure if they can
[4:04]	Sebastean Steamweaver:	Something I do with objects I sell, is in the prim count, include the count of any prims that an object might rez. I think people will end up doing the same with memory, for scripts in the objects that are rezzed which might take up that additional memory sace.
[4:04]	Babbage Linden:	rather than the stack-heap collision probelm
[4:04]	Gypsy Paz:	maybe an error() state would be nice
[4:04]	Gypsy Paz:	I mean, error() event
[4:05]	Sebastean Steamweaver:	includes*
[4:05]	Ceawlin Steamweaver:	Yes. It is very upsetting that there's no way to make something recover from a stack heap at all anymore, since llResetScript no longer works on stack-heaped stuff. :<
[4:05]	Eddi Decosta:	lol ok Gypsy, i just ask befor, for respect ㋡ hehe
[4:05]	Babbage Linden:	these are all good things to talk about
[4:05]	Ceawlin Steamweaver:	*OtherScript, that is
[4:05]	Babbage Linden:	for next time :-D
[4:05]	Babbage Linden:	thanks for coming everyone
[4:05]	Morgaine Dinova:	TC Babbage, and thanks for the info on the client-side scripting work. Who would be the right person to follow it up with?
[4:05]	Gypsy Paz:	maybe wipe the memory and trigger an error() event
[4:05]	Ceawlin Steamweaver:	Thanks Babbage!
[4:05]	Imaze Rhiano:	bye babbie
[4:05]	Babbage Linden:	and good luck with the HMAC-SHA1 debugging ;-)
[4:06]	Vextra Messing:	thanks Babbage.
[4:06]	Gypsy Paz:	thanks Babbage! twas an awesome office hours! very informitive
[4:06]	Eddi Decosta:	yeah babage, honestly im againts the limitation of script .. cause some people paid for hud .. and im not rassured ㋡
[4:06]	Christine Milneaux:	Hey Babbage, how do I save this conversation?
[4:06]	Sebastean Steamweaver:	Do you have chat logging enabled Christine?
[4:06]	Ceawlin Steamweaver:	I think someone usually posts a log on the wiki, Christine.
[4:07]	Xugu Madison:	Thanks Babbage!
[4:07]	Babbage Linden:	bye!
[4:07]	Babbage Linden:	have a good week