User:Babbage Linden/Office Hours/2010 03 31

Transcript of Babbage Linden's office hours:

[03:00]	Nock Forager:	Hi babbage
[03:00]	lonetorus Habilis:	yes, when the old function would take 51 seconds at best
[03:00]	Chaley May:	i would like all the prims i want to change at the same time
[03:00]	Chaley May:	hi Babbage
[03:01]	Cale Flanagan:	i was first on this sit:)
[03:01]	Talarus Luan:	Then you have to use LINK_SET in the call or something similar.
[03:01]	Opensource Obscure:	hello babbage! so timely!!
[03:01]	Actingill Igaly:	lol sorry
[03:01]	Babbage Linden:	hi everyone, how's it going?
[03:01]	Ceawlin Steamweaver:	Morning Babbage!
[03:01]	Command not recognized at this location.
[03:01]	Command not recognized at this location.
[03:01]	Talarus Luan:	OK
[03:01]	Morgaine Dinova:	'Morning all :-)
[03:01]	lonetorus Habilis:	pretty excited over 1.38 XD
[03:01]	Talarus Luan:	Playing with our new toys :D
[03:01]	Morgaine Dinova:	Hi Babbage!
[03:01]	Sheryl Mimulus:	it becomes nearly equivalent to llSetLinkPrimitiveParams, which does some what reduce the goal of introducing llSetPrimtiiveParamsNoDelay
[03:01]	lonetorus Habilis:	hey babbage
[03:01]	Opensource Obscure:	cool! my region runs on 1.38 and it seems to benefit from it
[03:01]	JB Hancroft:	gm, all :)
[03:01]	Babbage Linden:	glad to hear it
[03:02]	Babbage Linden:	ok, let's get an agenda together
[03:02]	Babbage Linden:	1.38 experiences sounds like it should go on it
[03:02]	Babbage Linden:	i would like to talk about script limits boundary conditions
[03:02]	Babbage Linden:	anything else?
[03:02]	lonetorus Habilis:	script limits
[03:02]	lonetorus Habilis:	;)
[03:03]	Sheryl Mimulus:	can we spend a little time talking about use cases for llSetLinkPrimtiiveParamsNoDelay?
[03:03]	Ardy Lay:	Script usage reporting on group owned land
[03:03]	ZenMondo Wormser:	I want to know more about c# scripting coming up.
[03:03]	Opensource Obscure:	roberto salubrius reported one of his HUDs seemed to be broken by the new server. as in Mono errors that didn't appear with previous servers.
[03:03]	JB Hancroft:	Any plans for APIs for the sim / script performance reporting (not just through the viewer)?
[03:03]	Ceawlin Steamweaver:	Yea I have a quick thing to mention with ppfast if there is time, but there's probably nothing to be done about it, so eh. :P
[03:03]	TKD Nitro HUD V2.0: TKD Nitro HUD V2.0 [script:TKD NITRO RUN V2.0] Script run-time error
[03:03]	TKD Nitro HUD V2.0: System.Runtime.Serialization.SerializationException: serializationStream supports seeking, but its length is 0
	at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.NoCheckDeserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler) [0x00000]
	at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (System.IO.Stream serializationStream) [0x00000]
	at LindenLab.SecondLife.Script.Deserialize (System.Byte[] object_data) [0x00000]
	at LindenLab.SecondLife.Script.Deserialize (System.Byte[] class_data, System.Byte[] object_data, System.Reflection.Assembly assembly) [0x00000]
[03:03]	Opensource Obscure:	here it is.
[03:04]	Opensource Obscure:	did the error appear in public chat?
[03:04]	Cale Flanagan:	scrip usage reporting in sandboxes? (atleast it wasnt on aditi)
[03:04]	Morgaine Dinova:	Yes
[03:04]	Sheryl Mimulus:	yes, its in the debug channel
[03:04]	Opensource Obscure:	sorry i'm still confused about that in V2
[03:04]	Opensource Obscure:	ok
[03:04]	Talarus Luan:	I have a modest proposal on a notecard I'd like to give you since I'm here. :D
[03:04]	Babbage Linden:	ok, so we have:
[03:05]	Opensource Obscure:	(( i can't provide more details about this error and i can't share the object. ask Roberto Salubrius if needed ))
[03:05]	Babbage Linden:	1.38 experiences
[03:05]	Babbage Linden:	c# scripting update
[03:05]	Babbage Linden:	script limits
[03:05]	Babbage Linden:	Mono errors
[03:05]	Xugu Madison:	(hi all)
[03:05]	Babbage Linden:	APIs for script usage
[03:05]	Babbage Linden:	that sounds like enough to be getting on with
[03:05]	Babbage Linden:	so, first off, 1.38, how are you finding it? the good, the bad, the bugs
[03:06]	Talarus Luan:	So far so good.
[03:06]	Chaley May:	i think 1.38 is great
[03:06]	Liisa Runo:	seems to be good ❤
[03:06]	Talarus Luan:	The new toys are luscious
[03:06]	Xugu Madison:	It's good! A few things we could do with still, but a great leap in the right direction
[03:06]	JB Hancroft:	huge win
[03:06]	Ardy Lay:	Script Info on group owned land is not working as expected.
[03:06]	Babbage Linden:	what's the problem with script info?
[03:07]	lonetorus Habilis:	its interesting to get a more closer feel of the raw speed of the sim using the ppfast function
[03:07]	Ceawlin Steamweaver:	It's ultra groovy. Only think I have noticed is that a bunch of slave scripts are still faster for some heavy operations, setting textures for one. I assume that's cos in the case of slave scripts you have N scripts getting N timeslices rather than just 1 script getting 1 timeslice, and there's not really anything to be done about that?
[03:07]	Chaley May:	yes i have one problem with script info it seems to count deactivated scripts too
[03:07]	Ardy Lay:	Always says 160kb in use and never lists scripts.
[03:07]	Ardy Lay:	Several of us looked and saw the same.
[03:07]	Babbage Linden:	ok, thanks ardy
[03:07]	Opensource Obscure:	I think i want some up-to-date scripting general guidelines
[03:07]	Babbage Linden:	is there a PJIRA for that?
[03:08]	Ardy Lay:	I haven't found one yet.
[03:08]	Ardy Lay:	There will be soon enough.
[03:08]	Babbage Linden:	please set one up if there isn't one
[03:08]	Babbage Linden:	thanks
[03:09]	Babbage Linden:	ceawlin, slave scripts will be faster, if you add enough of them
[03:09]	Babbage Linden:	as you're getting more script time slices
[03:09]	Babbage Linden:	but script limits will encourage you not to do that ;-)
[03:09]	Chaley May:	script info says i use 640kb in 10 scripts but 9 are deactivated
[03:09]	Babbage Linden:	chaley, deactivated scripts still used memory
[03:10]	Ceawlin Steamweaver:	Noddles. I was just a tiny bit disappointed that I can't change like, 100 textures fast enough to make something really smooth and interactive, but I guess that is kind of pushing it, huh? :P
[03:10]	lonetorus Habilis:	yeh, they have just been "paused"
[03:10]	Babbage Linden:	scripts use memory whenever they are rezzed
[03:10]	Babbage Linden:	ceawlin, HTTP textures may help there
[03:10]	Chaley May:	aww :(
[03:10]	Babbage Linden:	as it speeds up texture transmission around 2x
[03:10]	Kaluura Boa:	When will HTTP textures be officially supported?
[03:10]	Xugu Madison:	Can we get the ability to flat out kill scripts in a prim? Otherwise it's going to be hell on those of us with script stores full of inactive scripts....
[03:11]	Ceawlin Steamweaver:	Noddles. I am thinking the same, but at the risk of going OT, I think it will be a while begore V2 gets adopted widely. :<
[03:11]	Kaluura Boa:	I mean in-world...
[03:11]	Ceawlin Steamweaver:	*before, too
[03:11]	Babbage Linden:	also, there are 2 things going on here: you're updating the state of the world
[03:11]	Babbage Linden:	then the simulator is updating viewers
[03:11]	Kaluura Boa:	I will never adopt V2... Not before some major changes in it
[03:11]	Babbage Linden:	there is a throttle on the viewer update rate
[03:11]	Babbage Linden:	so it is possible to alter the simulators state too fast for viewers to keep up
[03:11]	Talarus Luan:	Is that the Agent Updates/sec stat in sim stats?
[03:12]	lonetorus Habilis:	what if they are boxed, and then boxed again, will they still east memory?
[03:12]	lonetorus Habilis:	eat
[03:12]	Ceawlin Steamweaver:	I also haven't found any good way to push data into media textures from outside sources. I have to put something in an iframe and write some JS to update it every second or two. >_>
[03:12]	Ceawlin Steamweaver:	But if someone knows a better way to do that, please IM me. :3
[03:12]	Babbage Linden:	lonetorus, objects that are inside objects are not rezzed
[03:12]	JB Hancroft:	Is the throttle server-side or can it be tweaked in a viewer?
[03:13]	Babbage Linden:	they are just inside the objects inventory
[03:13]	lonetorus Habilis:	so that answers xugu's question
[03:13]	Babbage Linden:	so scripts in the nested object won't count
[03:13]	Babbage Linden:	until you rez the nested object
[03:13]	Babbage Linden:	jb, the throttle used by the interest list system is the one you can tweak in the viewer
[03:13]	Xugu Madison:	lonetorus, unfortunately not... I have single prims containing script, notecard etc, and set to sell content (through object settings rather than a vendor)
[03:13]	Chaley May:	it seems like we need a way to have scripts completely turned off to me
[03:13]	lonetorus Habilis:	though, i wonder if thats goung to be possible to communicate to the ppl that sell many scripts
[03:13]	lonetorus Habilis:	or freebie stores
[03:13]	Babbage Linden:	but it is enforced in the sim
[03:13]	JB Hancroft:	/me nods... ok
[03:14]	Babbage Linden:	chaley, the way to turn them off is to derez them
[03:14]	Ovaltine Constantine:	Ok so here's what I dont get about the script memory reporting: Say an object has 4 (Mono) scripts. That'll use 256 KB right? So what purpose does this serve? How is this better than simply counting the scripts and multiplying by 64?
[03:14]	Chaley May:	but that doesnt help for scripts that need them at times
[03:14]	Morgaine Dinova:	Babbage, you might want to remove the "No office hour 2010-01-27" from the prim in front of you.
[03:14]	Talarus Luan:	down the road, we will get a llSetMemorySize() function
[03:15]	Ceawlin Steamweaver:	/me wants that, bad. Lol.
[03:15]	Xugu Madison:	Ovaltine, while it's good for finding out how much crud is in a HUD,I do worry it'll cause a back-lash against Mono scripts before we can drop memory usage
[03:15]	Morgaine Dinova:	:-)
[03:15]	Babbage Linden:	ovaltine, mono scripts currently use 64KB
[03:15]	Babbage Linden:	but eventually they will be able to set their reserved sizes
[03:15]	Babbage Linden:	first with small scripts, to less than 64KB
[03:16]	Babbage Linden:	and then, with big scripts to more than 64KB
[03:16]	Babbage Linden:	the former makes simple scripts like door scripts more reserved memory efficeint
[03:16]	Chaley May:	if you bring the possibility to animate lots of people with one script then i can remove a lot of these scripts :)
[03:16]	Babbage Linden:	the latter lets you make complex scripts without having to break them up and use link messages
[03:16]	Xugu Madison:	/me nods to Chaley "That's something we need desperately too..."
[03:16]	JB Hancroft:	In order to determine what a reasonable "max size" should be, will there any form of "high water mark"... how much memory a script has used, since reset?
[03:17]	Talarus Luan:	Not too likely.. the permissions system is a whole 'nother ball of wax. <.<
[03:17]	Ovaltine Constantine:	So Ill be able to say "Ok, this script only ever uses 10kb, so only reserve that much"?
[03:17]	Babbage Linden:	jb, the current memory functions give a high water mark
[03:17]	JB Hancroft:	Oh, I thought that was just "current mem" for some reason. thanks
[03:17]	Babbage Linden:	this brings me to the reserved memory boundary conditions discussion I wanted to have
[03:18]	Babbage Linden:	currently if your script hits its limit it stack-heap collides
[03:18]	Babbage Linden:	with mono and reserved memory, it could potentially fault up to higher memory usage
[03:18]	Babbage Linden:	if that memory is available in the memory pool
[03:18]	Liisa Runo:	/me thinks about the reasonable max memory use: the tier i pay is enough to add 8 gigabytes of memory to 4 servers, monthly
[03:19]	Ceawlin Steamweaver:	Throwing an exception that we could use to increase the heap with the new function and then continuing would be pretty awesome. <_<
[03:19]	Babbage Linden:	that would reduce the requirement on scripters to always get reserved memory exactly right
[03:19]	Talarus Luan:	Well, have a set size, and a max size. :)
[03:19]	Xugu Madison:	/me would like the ability to set soft and hard boundaries. A soft boundary is pre-reserved, using the model you're going for Babbage, but it will try to re-allocate up to the hard boundary if it exceeds the soft one
[03:19]	Babbage Linden:	and it would also avoid the need to change reserved memory sizes if we change the something on the simulator
[03:19]	JB Hancroft:	Babbage - that would nice... to not have a hard failure. Also... As Liandra suggests, a way to know it's happened :)
[03:19]	Babbage Linden:	(going to 64 bit for example)
[03:20]	Babbage Linden:	so, it reduces the load on scripters
[03:20]	Babbage Linden:	but it increases the complexity on residents
[03:20]	Babbage Linden:	as they may turn up to their land and find that scripts have stopped
[03:20]	Babbage Linden:	because they tried to fault, but failed
[03:20]	Babbage Linden:	it would require more management from residents
[03:20]	Ceawlin Steamweaver:	No different than finding that they have stack-heaped. >_>
[03:20]	Xugu Madison:	Can't that happen already, anyway?
[03:20]	Babbage Linden:	and more UI to make it clear what's happening
[03:21]	Babbage Linden:	right, that's my argument, they can run out of memorynow
[03:21]	Babbage Linden:	we're currently debating this inside linden
[03:21]	Babbage Linden:	and I'd like to know your thoughts
[03:21]	Morgaine Dinova:	Can owners of no-mod scripts set the memory parameters for them?
[03:21]	Xugu Madison:	Yeah, make it clear in UI. I still think that having to re-compile every script if we want to get it below 64kb memory usage is a bit nuts, for reference...
[03:21]	ff 1.2:	Too many HTTP requests too fast.
[03:21]	Babbage Linden:	always hard limits, or limits that can be soft if they need to be?
[03:21]	Ovaltine Constantine:	Speaking of UI. When, if ever, will be be able to see the script time (not just memory) of our attachments
[03:22]	Babbage Linden:	xugu, that is also the question
[03:22]	Ceawlin Steamweaver:	I think, ideally, if there's unused memory available, we should be able to use it if we need it, until something else reserves some of it. Prolly be a pain in the rear to implement all that though, eh? :P
[03:22]	Babbage Linden:	if we're going to allow this faulting behaviour, when should we use it?
[03:22]	Babbage Linden:	we could for example, set mono and LSL reserved memory to 16KB and let them all just fault up
[03:22]	Xugu Madison:	YES!
[03:23]	Babbage Linden:	but that makes it very hard for residents to know what's going on
[03:23]	Morgaine Dinova:	Users of no-mod scripts need to be able to do all these things too
[03:23]	Xugu Madison:	I'm not sure. I like to think people are fairly used to the idea of memory allocation by now...
[03:23]	Ceawlin Steamweaver:	Also, how do you decide what to do when something goes haywire and starts allocating endlessly?
[03:23]	Babbage Linden:	right, at the moment no-mod scripts will use 64KB
[03:23]	Babbage Linden:	as that's us being conservative
[03:24]	Talarus Luan:	I think I like the concept of having both a soft and a hard limit set by the scripter.
[03:24]	Babbage Linden:	if we set no-mod scripts to 16KB and let them fault up, that may be a better alternative
[03:24]	JB Hancroft:	I think Morgaine is onto something... for the end-user to be able to tweak memory for a no-mod, and not require the scripter to do so.
[03:24]	Talarus Luan:	..and an ACCURATE current memory use function
[03:25]	Talarus Luan:	With this "unlimited faulting" behavior, I think it is just going to encourage lazy scripting and horribly confused users.
[03:25]	Ceawlin Steamweaver:	Tal++. But I also think that while y'all are implementing all this stuff, we really need some way to be able to recover from memory issues. We used to be able to have another script reset one that had scack-heaped, but that hasn't worked for ages. It makes for some frustrating support issues when you can't code your stuff to recover from faults on its own. :<
[03:25]	Babbage Linden:	talarus, agreed, that is what some of the linden opinions are
[03:25]	Ceawlin Steamweaver:	*stack-heaped, too
[03:26]	Morgaine Dinova:	Well I think user-settable memory usage is a throwback to the 70's. But if we have to have it, then users of no-mod scripts need to have it too, because unfortunately that's the majority of scripts.
[03:26]	Babbage Linden:	caewlin
[03:26]	JB Hancroft:	Babbage, there's something about this which is different than most systems that I'm used to. In general, people are used to less memory = worse performance. We're talking about less memory = breakage.
[03:26]	Babbage Linden:	right
[03:26]	Talarus Luan:	I like having the script be self-aware of its own limitations and work within them, interfacing with the user as needed to explain why it can't do X because X requires too much in terms of resources.
[03:27]	Babbage Linden:	talarus, i like that too
[03:27]	Talarus Luan:	Helluva lot better than "ZOMG! STACK/HEAP ERROR!!!"
[03:27]	Babbage Linden:	there are 2 types of scripts to consider
[03:27]	Ceawlin Steamweaver:	I don't mind having to handle an OmgReduceYourMemoryFootprint exception, if we can just -have- something to use for recovery, lol. :P
[03:27]	Talarus Luan:	What does anyone do at that point?
[03:27]	Babbage Linden:	old ones that don't know about memory limits, they need to do something sensible
[03:27]	Morgaine Dinova:	Talarus: not much point interfacing with the user when it's no-mod and the user can't do anything about it.
[03:27]	Babbage Linden:	and new ones that can know
[03:27]	Babbage Linden:	so, an old Mono script, knows nothing about its own memory
[03:28]	Babbage Linden:	we move the simulator to 64 bit and now it needs to use 90KB of memory
[03:28]	Babbage Linden:	it can't just explode
[03:28]	Talarus Luan:	Well, I mean, interfacing with the user by saying "sorry, I can't store 1001th teleport location.. expand your teleport HUD today at xyz store!"
[03:28]	Babbage Linden:	we could change its reserved memory to 128KB
[03:28]	Actingill Igaly:	a low_memory event - in which you can code various options depending on the application
[03:28]	Actingill Igaly:	reduce the size of lists etc
[03:28]	Babbage Linden:	but not all Mono scripts will need more than 64KB
[03:28]	Talarus Luan:	Rather than just getting a stack/heap error, or have it stop running due to script limits.
[03:29]	Babbage Linden:	so, letting the ones that need to fault up to 128KB may make sense
[03:29]	Morgaine Dinova:	Talarus: spam as a coercive marketting feature? No thanks.
[03:29]	Babbage Linden:	meanwhile, the self aware mono script notices that it's using more memory for some reason
[03:29]	Talarus Luan:	That's not what I was suggesting, Morgaine.
[03:29]	Babbage Linden:	because it's caught an exception or something
[03:29]	Babbage Linden:	and does something sensible
[03:29]	Babbage Linden:	reducing cache sizes or something
[03:29]	Ceawlin Steamweaver:	And if your footprint still sucks on that low_memory event's exit, it stack-heaps? What happens when you are evul and just run a dead loop in that event and keep allocating moar moar moar?
[03:29]	JB Hancroft:	I wonder how much script logic in a sim will be taken up with script memory management overhead and hacks?
[03:30]	Xugu Madison:	I'm really liking the idea that we ditch script-set memory usage boundaries, and stick with faulting up from 16 or 32kb...
[03:30]	Talarus Luan:	Just saying that the scripter can make the script aware of the problem and handle it with the user in a graceful fashion, rather than letting the user plow into the brick wall of technical jargon.
[03:30]	Babbage Linden:	JB, I think it will be OK, these are boundary conditions
[03:30]	JB Hancroft:	ok
[03:30]	Babbage Linden:	most of the time scripts will just rock along within their limits as now
[03:30]	Actingill Igaly:	i dont think it should be up to scripters to have to constantly check memory at every point in their script - that just adds to code and increases memory. we need an exception event
[03:30]	Talarus Luan:	"Know your limits"
[03:30]	Babbage Linden:	actingill, agreed
[03:30]	Morgaine Dinova:	Talarus: I'm just making the point that memory usage belong to the user parameters set, not the creator's parameters set. So the user should be able to control all aspects of memory usage, independent of whether a script is no-mod.
[03:30]	JB Hancroft:	... just don't want to invent a whole new realm of workarounds and unnatural behavior in scripts
[03:30]	Ceawlin Steamweaver:	JB: Surely less than is taken with all this multi-script synchronization foolishness and having to keep 10k or so free just so you can copy lists when the get passed by value. X_x
[03:30]	Babbage Linden:	there needs to be an event or an exception when memory is running out
[03:31]	Xugu Madison:	/me nods "in 64kb of Mono, it's already tough to get all the error handling you might want, in"
[03:31]	Actingill Igaly:	stress *running out* not *ran out*
[03:31]	Babbage Linden:	xugu, soon those scripts will be able to ask for more than 64KB if they need them
[03:31]	JB Hancroft:	Babbage - is there a chance we can get an API to reset a stack-heap collision faulted script?
[03:31]	Talarus Luan:	Morgaine: I disagree. The user's parameter set should ALWAYS be a subset of the scripter's parameter set. To do otherwise is, to put it simply, dangerous.
[03:31]	Babbage Linden:	anyway, that's what we're currently noodling on in the script limits discussion
[03:32]	Babbage Linden:	i'd appreciate your thoughts
[03:32]	Xugu Madison:	mmmm, noodle..
[03:32]	Actingill Igaly:	what about an error event that passes all current debug messages, and can include memory errors, then we can deal with specific issues without end users getting involved
[03:32]	Babbage Linden:	anything else people wanted to ask about script limits before we move on?
[03:32]	Talarus Luan:	The whole notion of bugs is most often where the user exceeded the scripter's expectations in some way.
[03:32]	Morgaine Dinova:	Talarus: memory used belong to the user, not to the creator. Unless you're advocating that memory used be assigned to the creator's budget. :-)
[03:33]	Xugu Madison:	I love faulting up, personally. I don't think I can give realistic estimates of memory usage for any of my scripts except the ones with very fixed allocation. A lot of them, for example, will store configuration data from the user, and that can vary massively...
[03:33]	Talarus Luan:	That may be, but good design doesn't work that way.
[03:34]	Xugu Madison:	One last question on reporting, actually. Is the memory usage shown for the one parcel, or all parcels belonging to the same resident, on the same sim?
[03:34]	Ceawlin Steamweaver:	I dig the faulting up too, but also push for a way to deal with memory issues without just crashing, or at least being able to have something reset the script after it crashes.
[03:34]	Talarus Luan:	Crashing data scripts would be very messy.
[03:34]	Actingill Igaly:	some sort of perminant storage would go a long way to reducing memory needs in any case...
[03:34]	Xugu Madison:	a memory_usage_increased() event could be nice
[03:34]	Morgaine Dinova:	Talarus: good design never places the user at the mercy of the creator's incompetence.
[03:34]	Talarus Luan:	Reset = lost data.
[03:35]	Talarus Luan:	No, good design means the creator compensates for the user's incompetence. :)
[03:35]	Xugu Madison:	Babbage, I presume script allocations would reset to the minimum if the script itself is reset?
[03:36]	Babbage Linden:	xugu, that's how I imagine it working, yes
[03:36]	JB Hancroft:	Babbage, I do have one question...
[03:36]	Morgaine Dinova:	Talarus: nice utopic ideal, except that sadly in the real world it's full of incompetent developers. SL's scripting system is intended for the masses.
[03:36]	Babbage Linden:	you reserve 64KB for a script, it's faulted up to 128KB it goes back to 64KB when it's reset
[03:36]	Babbage Linden:	ok, let's move on
[03:36]	Talarus Luan:	An incompetent scripter isn't going to make this particular problem any better.
[03:37]	JB Hancroft:	ok... I'll send it in a notecard :)
[03:37]	Babbage Linden:	but please let me know what your thoughts are here
[03:37]	Babbage Linden:	so C# scripting update
[03:37]	Morgaine Dinova:	Talarus: precisely. Which is why I'm saying that the user should have control for no-mod scripts.
[03:37]	Babbage Linden:	thanks to Morgaine's suggestion we've been looking at what ECMA standardises
[03:37]	JB Hancroft:	++Cookie
[03:38]	Babbage Linden:	and for the first version of the C# API we're going to expose the ECMA base class library, limited with the Silverlight 2 security attributes
[03:38]	Ceawlin Steamweaver:	\o/
[03:38]	Babbage Linden:	and allow C# 2 scripting
[03:38]	Xugu Madison:	Awesome :)
[03:38]	Babbage Linden:	(as it's the latest ECMA standardised version)
[03:38]	Babbage Linden:	we needed C# 2 to get security attributes anyway
[03:38]	Talarus Luan:	Just curious, but is there any timeline for languages OTHER THAN C#?
[03:39]	Morgaine Dinova:	Blue Kitty always has the best solutions --- http://www.blip.tv/file/3407015 :-)
[03:39]	Babbage Linden:	talarus, 2011, hopefully
[03:39]	Babbage Linden:	(but I need to sell that separately)
[03:39]	JB Hancroft:	well, not "always" ;)
[03:39]	Talarus Luan:	Is there anything we can do to help that along?
[03:39]	Ceawlin Steamweaver:	What will that entail? Are you still gonna let us just upload assemblies eventually? ;P
[03:39]	Babbage Linden:	I hope so caewlin
[03:39]	Ceawlin Steamweaver:	:d
[03:39]	Ceawlin Steamweaver:	That'll be super tasty.
[03:40]	Xugu Madison:	Babbage, I was rather hoping there would be a script-bytecode-upload cap or similar, and therefore other languages may just mysteriously turn up in the asset server somehow
[03:40]	Babbage Linden:	xugu, yes that would be the plan
[03:40]	Xugu Madison:	/me types too slow :(
[03:40]	Babbage Linden:	but we want to run with the Moonlight 2 CoreCLR sandbox for a while to be happy with it first
[03:41]	Babbage Linden:	at the moment you'd need to get gmcs to generate invalid bytecode that the sandbox verifies
[03:41]	Babbage Linden:	which is harder
[03:41]	Babbage Linden:	I looked at the LibOMV Vector and Quaternion types
[03:42]	Morgaine Dinova:	Babbage: will the CoreCLR sandbox be used unmodified, so that we can nuke the hell out of it locally for security testing, or are you modifying it?
[03:42]	Babbage Linden:	but in the end decided to only overload operators that have the same syntax
[03:42]	Babbage Linden:	so, we have operater + and - on Vectors
[03:43]	Babbage Linden:	but DotProduct and CrossProduct to be explicit
[03:43]	Ceawlin Steamweaver:	Babbage++. operator overloading abuse bugs the bjesus out of me. :3
[03:43]	Babbage Linden:	I understand it's something of a religious debate
[03:43]	Babbage Linden:	so I imagine lots of dicussion about that when we release the API
[03:44]	Ceawlin Steamweaver:	If people want them overloaded more, they can just derive their own classes, right? >_>
[03:44]	Babbage Linden:	so, the v1 strawman API is looking like C#2 + ECMA-BCL (with Silverlight 2 limits) + ll* methods + Vector, Quanterion, ArrayList, Key, string
[03:45]	Babbage Linden:	ceawlin, they could define their own types
[03:45]	Talarus Luan:	Will keys not be strings anymore, but actual binary UUIDs?
[03:45]	Babbage Linden:	but Vector and Quaternion are value types
[03:45]	Ceawlin Steamweaver:	Oh, ew. ;P
[03:45]	Babbage Linden:	so they can be layout compatible with the C++ types and marshalled efficiently
[03:46]	Babbage Linden:	but, you could define your own class with whatever operators you like and then define a LindenLab.SecondLife.Vector operator too
[03:46]	Babbage Linden:	which, if you made it implicit would mean you could just pass your type to LindenLab.SecondLife.Library methods at let C# do the work
[03:47]	Babbage Linden:	Byron is currently working on getting the API annotted with security attributes at build time
[03:47]	Babbage Linden:	and Rand is working on the documentation that we'll be releasing soon
[03:48]	Babbage Linden:	I'm looking forward to discussing the API with you shortly :-D
[03:48]	Ceawlin Steamweaver:	What's the current ETA on us being able to enter the playground, too? :P
[03:48]	Babbage Linden:	the beta is planned for Q3
[03:48]	Ceawlin Steamweaver:	Wewt
[03:48]	Chaley May:	i wont be able to discuss it until i understand it :)
[03:48]	Babbage Linden:	we still have quite a lot of work to do to make the UThreadInjector work with C# assemblies
[03:49]	Babbage Linden:	(.NET 2 assemblies specifically)
[03:49]	Babbage Linden:	but, we can iterate on the API while we work on that
[03:49]	Xugu Madison:	In short, sounds good, but I do fear we won't really know until we get to play with it...
[03:49]	Babbage Linden:	so plan to have the API documentation out in Q2
[03:49]	Xugu Madison:	:)
[03:49]	JB Hancroft:	Q2 = excellent
[03:49]	Babbage Linden:	I expect that API documentation to be pretty opaque to most people
[03:50]	Babbage Linden:	but hope that there are a smattering of C# experts who will help us improve it while we work on the UThreadInjector and sand box
[03:50]	Babbage Linden:	so, last 2 things
[03:50]	Babbage Linden:	Mono errors in 1.38
[03:51]	JB Hancroft:	/me suggests that whatever is in the water or coffee in Babbage's office, also be shared with other places... great push and progress :)
[03:51]	Babbage Linden:	please make a PJIRA for it with repros if there isn't one already
[03:51]	Ceawlin Steamweaver:	( Yea, I could use some of that. sooo far behind. X_x )
[03:51]	Babbage Linden:	(I've got the stack trace in the chat log, thanks)
[03:52]	Babbage Linden:	the last one was APIs for script usage I think
[03:52]	Opensource Obscure:	(ok)
[03:52]	Babbage Linden:	at the moment it's a cap that returns LLSD
[03:52]	Babbage Linden:	so, it should be relatively easy to use from other viewers
[03:52]	Morgaine Dinova:	/me waves at Aimee
[03:53]	Aimee Linden:	/me Mexican waves back
[03:53]	Morgaine Dinova:	lol :-)
[03:53]	Babbage Linden:	there is a group at the lab currently looking at our public APIs
[03:53]	Babbage Linden:	once we have a plan there I will suggest making script usage available
[03:53]	Xugu Madison:	Babbage, can I get you to look at the feasibility of http://jira.secondlife.com/browse/SVC-1593 BTW. Could help simplify a lot of vendors (where currently they had all sorts of madness to ensure delivery happens)
[03:54]	JB Hancroft:	good
[03:54]	Xugu Madison:	Great!
[03:54]	Babbage Linden:	as we don't give all information to everyone we'd need to work out how to do auth on that API
[03:54]	Morgaine Dinova:	Oh christ, not more NDAs
[03:54]	Babbage Linden:	so it's not as easy as just setting up a REST service
[03:55]	Xugu Madison:	Morgaine, I think Babbage means how do they know it's the sim owner asking for the information....
[03:55]	Babbage Linden:	no, morgaine, we use resident relationship with land to decide which script information to send out
[03:55]	Ann Otoole:	whats wrong with NDAs? At Microsoft you sign them daily rofl
[03:55]	JB Hancroft:	Why is there sensitivity about an API that pulls the same info on my scripts that I could get manually through the viewer?
[03:55]	Babbage Linden:	so, we'd need to have some kind of auth in the web API if we were going to follow the same model
[03:55]	Morgaine Dinova:	Ah phew, thanks Babbage, my misunderstanding. Dislike NDAs intensely.
[03:55]	Babbage Linden:	JB, you will get summaries about all land
[03:56]	Babbage Linden:	but you don't get details on objects unless you're the owner or manager
[03:56]	Morgaine Dinova:	/me nods
[03:56]	JB Hancroft:	ok
[03:56]	Babbage Linden:	(so, you would start with a summary only web API...)
[03:56]	Babbage Linden:	ok, we have 4 minutes left, anything else?
[03:57]	Ovaltine Constantine:	I wanted to ask: (Almost) all the scripts in the tool Im developing are LSL. What are the pros and cons of compiling them all to Mono right now? I only see cons, they use 4x as much memory, and make sims freeze when you rez them (has that been fixed all the way?)
[03:57]	Xugu Madison:	HTTP texture loading?
[03:57]	Babbage Linden:	ah yes
[03:57]	Babbage Linden:	that will hopefully be in viewer 2.1
[03:57]	Opensource Obscure:	up-to-date scripting tips and guidelines to write efficient scripts!
[03:57]	Babbage Linden:	the server and viewer code is done
[03:57]	Babbage Linden:	but we need to test and deploy it carefully
[03:58]	Babbage Linden:	as, eventually, it will move ~90% of the LL traffic to HTTP from UDP
[03:58]	Babbage Linden:	which is a big change in how our network is used
[03:58]	Babbage Linden:	so, we need to talk to operations and work out how we can deploy it in stages and monitor the network carefully
[03:59]	Opensource Obscure:	sounds intriguing
[03:59]	Xugu Madison:	but it's SOOOO much more fun to just throw stuff live and watch it flail...
[03:59]	Opensource Obscure:	lol
[03:59]	Talarus Luan:	HTTP (nee TCP) is great for reliable/block transfers, but for temporally-dependent information, you can't really beat UDP.
[03:59]	JB Hancroft:	heh
[03:59]	Ceawlin Steamweaver:	Ovaltine: afaik, mono scripts don't actually use memory until they allocate it? They can use up to 64k, but until you use it all, they're actually only using what they've used? They don't use a preallocated contiguous memory space like LSO does?
[04:00]	Opensource Obscure:	(more details re: my request -> i'm not asking for specific tips right now .. but i'd like to see something in the near future .. on the wiki or on the blogs .. about that )
[04:00]	Babbage Linden:	ceawlin, yes
[04:00]	Babbage Linden:	opensource, yes, that is a good idea
[04:00]	Babbage Linden:	I'd like to do something internally too
[04:00]	Xugu Madison:	Oh! Memory usage reporting of shared bytecode?
[04:00]	Babbage Linden:	"new LSL functions should not sleep scriipts, but should us script pool throttles")
[04:00]	Xugu Madison:	Restricted to same parcel is done...
[04:01]	Ovaltine Constantine:	Even so, if someone on Viewer 2 uses my tool they might go "Hey, this things sucks up a lot of memory" even if its not using nearly as much as the UI claims
[04:01]	Babbage Linden:	xugu, memory usage of shared bytecode is on our list
[04:01]	Babbage Linden:	but the UI is hard
[04:01]	Opensource Obscure:	ovaltine: but if they like your shoes, they will ignore that.
[04:01]	Babbage Linden:	we need to talk to some UX people about it
[04:01]	Xugu Madison:	Those of us who make a lot of shared scripts are going to have a really bad year without that...
[04:02]	Babbage Linden:	xugu, yes I understand
[04:02]	Babbage Linden:	ok, times' up!
[04:02]	Morgaine Dinova:	Don't talk to the 2.0 UX people, since they got the UX totally wrong.
[04:02]	Xugu Madison:	Thanks Babbage!
[04:02]	Babbage Linden:	great discussion, thanks everyone
[04:02]	Ceawlin Steamweaver:	Thanks Babbage!
[04:02]	Morgaine Dinova:	Thanks Babbage, very informative as usual, appreciate that :-)
[04:02]	JB Hancroft:	Thanks, Babbage. Very cool.
[04:02]	Opensource Obscure:	yawn, morgaine. i like that UI.
[04:02]	Talarus Luan:	I don't :P
[04:02]	Babbage Linden:	please let me know your thoughts on the memory faulting discussion
[04:02]	Kaluura Boa:	Me neither
[04:02]	Opensource Obscure:	oh, let's make statistics.
[04:02]	Babbage Linden:	and I'll see you next week
[04:02]	Chaley May:	anyoen know where i can go to see how much memory some of my scripts use without owning land?
[04:02]	JB Hancroft:	tc
[04:02]	Opensource Obscure:	bye babbage!
[04:03]	Opensource Obscure:	bye everybody