User:Babbage Linden/Office Hours/2010 02 24

Transcript of Babbage Linden's office hours:

[3:06]	Jonathan Yap:	Hey Babbage
[3:06]	Chaley May:	it would be better if it was a brighter color
[3:06]	Kaluura Boa:	Hi Babbage
[3:06]	Sahkolihaa Contepomi:	Hey Babbage.
[3:06]	Chaley May:	hi babbage :)
[3:06]	Babbage Linden:	morning everyone :-D
[3:06]	Nock Forager:	hello Babbage
[3:06]	Babbage Linden:	it's lovely here in Brighton today
[3:07]	Kaluura Boa:	Give us some good news about scripting...
[3:07]	Morgaine Dinova:	Sure, the non-transparency of the chat windows is a Fail, because it obscures the view. But the right-hand bar does not obscure the view because it resizes the view, so it;s an improvement. (But done badly)
[3:07]	Sahkolihaa Contepomi:	It's cloudy in Tamworth. :(
[3:07]	Chaley May:	cloudy in leicester too
[3:07]	Morgaine Dinova:	Hiya Babbage! We thought you were in the US doing SL Pro :-)
[3:07]	Kaluura Boa:	I wouldn't mind it if I were able to get rid of it... totally
[3:07]	Imaze Rhiano:	hi Babbage!
[3:07]	Babbage Linden:	hi morgaine, no I'm in the UK
[3:07]	Morgaine Dinova:	Cool :-)
[3:08]	Babbage Linden:	unfortunately my SL Pro talk is at 4PM today
[3:08]	Babbage Linden:	so I'll be up late tonight
[3:08]	Chaley May:	i guess it would defeat the purpose of SL if he had to travel to the US to do SL Pro
[3:08]	Babbage Linden:	OTOH, it gives me a good few hours to get my talk sorted
[3:08]	Morgaine Dinova:	Ouch. Well welcome to the body clock suffering we have too :-(
[3:08]	Babbage Linden:	so, what do you want to talk about today?
[3:09]	Morgaine Dinova:	Client-side scripting
[3:09]	Liisa Runo:	Babbage, can you tell us if there is still known permission exploit threat? im hearing rumours about yes and no
[3:09]	Kaluura Boa:	Anything but client 2.0...
[3:09]	Morgaine Dinova:	Have you read the immense thread on client-side scripting in opensource-dev, Babbage?
[3:09]	Babbage Linden:	I've seen the immense thread, I haven't read through it
[3:10]	Babbage Linden:	and I shouldn't talk about client side scripting as I'm not working on it
[3:10]	Morgaine Dinova:	Are you at liberty to talk about it?
[3:10]	Morgaine Dinova:	Ah
[3:10]	Babbage Linden:	just trying to keep it compatible with the server side scripting I'm working on
[3:10]	Babbage Linden:	I'm going to keep the topics covered here to the projects I'm working on
[3:11]	Morgaine Dinova:	Babbage: well that's the problem. It has no business being compatible with the server side, because that doesn't meet user requirements
[3:11]	Babbage Linden:	I'm happy to be open about those, but I shouldn't speak for other projects I'm not working on
[3:11]	Babbage Linden:	what I'm interested in is improving the server side second life scripting experience
[3:11]	Babbage Linden:	and there's a lot of low hanging fruit there, so that's what I'm working on
[3:12]	Morgaine Dinova:	kk
[3:12]	Babbage Linden:	some kind of client side scripting would be useful at some point in the future
[3:12]	Babbage Linden:	and I'm trying to make sure that the server side scripting plays nicely with that
[3:12]	Leia Lulu:	I would like to know what the proposed dates are for limiting scripts per parcel
[3:12]	Latif Khalifa:	yeah, nobody really touched scripting on the server for the past 4 years or so
[3:12]	Chaley May:	you mean like direct communication from server side scripts to client side? instead of client intercepting things?
[3:12]	Latif Khalifa:	except for http-in
[3:12]	Babbage Linden:	and http-out
[3:13]	Latif Khalifa:	yeah, but it does feel like like scripting is neglected child
[3:13]	Babbage Linden:	right, so I'm trying to fix that now
[3:13]	Latif Khalifa:	cool
[3:13]	Babbage Linden:	and have been lobbying for it internally for a while
[3:13]	Latif Khalifa:	how is the c# scripting project coming?
[3:13]	Jonathan Yap:	Is it possible to comment on when we will be able to view script memory usage?
[3:13]	Babbage Linden:	ok, so, C# development update
[3:14]	Babbage Linden:	script usage
[3:14]	Morgaine Dinova:	Well this is the summary of the user requirements for client-side scripting, it covers all types --- the two indented blocks, ignore rest of post -- https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000173.html
[3:14]	Babbage Linden:	any other agenda items?
[3:14]	Leia Lulu:	I would like to know what the proposed dates are for limiting scripts per parcel
[3:15]	Imaze Rhiano:	shared media in SL2 - how is it scripting working? can you hide all control panels? can you use with HUDs?
[3:15]	Jonathan Yap:	This might be of some interest http://wiki.secondlife.com/wiki/LlSetPrimMediaParams
[3:17]	Babbage Linden:	any more? c# script usage shared media?
[3:17]	Latif Khalifa:	that will do nicely
[3:17]	Babbage Linden:	ok, let's get going
[3:17]	Morgaine Dinova:	I vote for the shared media topic too
[3:17]	Cerdita Piek:	may be SVC-3895?
[3:18]	Babbage Linden:	ok, done
[3:18]	Saijanai Kuhn:	I can display a webpage from localhost but not sure how to combine that with scripting right now. The only thing I've gotten so far is touch to work via the right-click menu
[3:18]	Babbage Linden:	so, C# update
[3:18]	Babbage Linden:	byron is currently getting Mono 2.6.1 embedded in the simulator
[3:19]	Babbage Linden:	our current sprint is to enable the CoreCLR sandbox in the simulator
[3:19]	Babbage Linden:	so, we're making the changes to the simulator to turn the sandbox on
[3:19]	Babbage Linden:	and then investigating the Mono tuner tools
[3:20]	Morgaine Dinova:	Mono 2.6.1 has finally made it into Gentoo unstable/test I see
[3:20]	Babbage Linden:	which modify the Mono .NET framework to produce the Silverlight profile
[3:20]	Babbage Linden:	we plan to use the same machinery to produce an SL profile
[3:20]	Babbage Linden:	which will likely be a subset of the Silverlight 2.0 profile
[3:21]	Babbage Linden:	minus the GUI frameworks
[3:21]	Morgaine Dinova:	A Mono profile is a package of configs? Or something else?
[3:21]	Babbage Linden:	but hopefully including things like collections and XML/JSON libraries
[3:21]	Morgaine Dinova:	Or are you talking about profiling?
[3:21]	Babbage Linden:	a profile in this context is a set of class libraries available on a platform
[3:21]	Latif Khalifa:	Morgaine, is more like a platform target
[3:22]	Babbage Linden:	let me get you the link to the Silverlight 2.0 profile
[3:22]	Morgaine Dinova:	Aha. Like a Cg profile, kk
[3:23]	Babbage Linden:	here's the silverlight 2 profile http://msdn.microsoft.com/en-us/library/cc838194%28VS.95%29.aspx
[3:23]	Babbage Linden:	we'd like to expose as much as we can from that profile
[3:23]	Babbage Linden:	I'd like to know your thoughts on which pieces you'd find useful
[3:23]	Babbage Linden:	and which would be problematic
[3:23]	Babbage Linden:	so, there is internal discussion on that
[3:23]	Latif Khalifa:	Babbage, do you plan to reuse the same user mode microthreding implementation with opcode injection that you use for LSL?
[3:24]	Morgaine Dinova:	Nothing that isn't standardized in ECMA, period. I'm sure you know why.
[3:24]	Babbage Linden:	as well as investigation in to how to use the machinery to produce the annotated and tuned assemblies
[3:25]	Babbage Linden:	in addition to the subset of Silverlight 2.0 APIs there will obviously be access to the ll* methods
[3:25]	Babbage Linden:	those will be exposed as public static methods as they need to be accessible from non OO languages like LSL
[3:26]	Babbage Linden:	(you'll still be able to build OO wrappers of course)
[3:26]	Babbage Linden:	we're considering whether we want to implement some of those wrappers
[3:26]	Babbage Linden:	and also designing the interfaces for Vectors and Quaternions that will be exposed to C# scripts
[3:27]	Babbage Linden:	there are already Vector and Quanternion classes used under the hood by LSL scripts running on Mono
[3:27]	Babbage Linden:	but as you'll be using them directly in C# we need to carefully consider the APIs for convinience and public consumption
[3:27]	Saijanai Kuhn:	big issue will be better string-handling/parsing classes I think
[3:28]	Babbage Linden:	yes, parsing and formatting is a big deal
[3:28]	Babbage Linden:	as LSL is a DSL in the sense that it has native support for Vectors, Quaternions and Lists
[3:28]	Latif Khalifa:	standard c# string class will do nicely there
[3:29]	Babbage Linden:	we want to make sure we have a slick API for those types in C#, so that working with them is not more painful in C#
[3:29]	Xugu Madison:	some method for reading in a full notecard and breaking it down into key/value pairs would take a lot of code off my stuff, actually...
[3:29]	Babbage Linden:	we use the standard C# string class for strings
[3:29]	Morgaine Dinova:	People will be able to use their own class libraries for portable stuff like strings and lists and parsing, so you don't need to provide that. Indeed, providing it will be very bad, since it'll make you non-standard.
[3:29]	Latif Khalifa:	Babbage, about events, I trust we can have native c# style for events like touch?
[3:30]	Saijanai Kuhn:	Morgaine, I disagree. standard libraries for SL-specific stuff would be very useful
[3:30]	Babbage Linden:	and a wrapped C# string class for Keys so that we can differentiate between strings and keys in Lists
[3:30]	Babbage Linden:	we're currently using ArrayLists for Lists
[3:30]	Morgaine Dinova:	Sai: I'm not talking about SL-specific stuff. I'm talking about string and parsing, which is generic
[3:30]	Saijanai Kuhn:	well, a notecard parser is SL-specific, for example.
[3:30]	Babbage Linden:	but may use object arrays instead
[3:30]	Babbage Linden:	as in many use cases you build lists of literals
[3:31]	Babbage Linden:	and so initialise an object array to just pass to an ArrayList constructor
[3:31]	Morgaine Dinova:	A notcard parser is NOT needed. Just a notecard to string function. Then use standard C# for manipulating the strings.
[3:31]	Xugu Madison:	Morgaine, given the memory constraints we really do need SL-specific stuff
[3:31]	Babbage Linden:	morgaine, we still need to add parsing and formatting for Vectors and Quaternions
[3:31]	Morgaine Dinova:	Yes, agreed, because those are SL-specific.
[3:31]	Babbage Linden:	they should both implement IFormatable and or ToString for example
[3:32]	Xugu Madison has scripts that use something like half their memory allowance just for notecard parsing
[3:32]	Babbage Linden:	so you get something better than "Vector" when you cast to string
[3:32]	Latif Khalifa:	Babbage, perhaps take a look at our implementation in libomv. It's opensource and BSD
[3:32]	Imaze Rhiano:	public static bool TryToParse( string str, out Vector vector );
[3:32]	Latif Khalifa:	we have all SL specific types implemented, Vector, Quat, Color, UUID, etc
[3:33]	Babbage Linden:	xugu, if we are able to expose XML and JSON parsing from the Silverlight APIs that will enable easy notecard parsing as well as internet interop
[3:33]	Babbage Linden:	latif, I will definitely look at the opensim implementations
[3:34]	Babbage Linden:	(which is presumably what you're refering too?)
[3:34]	Babbage Linden:	could you point me to the docs/source?
[3:34]	Latif Khalifa:	Babbage, yes opensim uses libomv's types
[3:34]	Latif Khalifa:	sure
[3:34]	Babbage Linden:	ok, thanks
[3:34]	Xugu Madison:	Babbage; I like the theory, but we need formats that are easy for people to understand. Being able to give a parser a notecard of "key=value" pairs, a list of valid keys and their types, and it does the validation would save a lot....
[3:35]	Morgaine Dinova:	Latif: does Opensim use libomv as a dependency, or have they just grabbed a snapshot of your code?
[3:35]	Babbage Linden:	xugu, hopefully we will get to the point where you will be able to share libraries in SL
[3:35]	Morgaine Dinova:	I mean an external dependency
[3:35]	Babbage Linden:	and we'll also factor bytecode sharing in to memory use
[3:35]	Xugu Madison nodnods
[3:35]	Babbage Linden:	then you could write your key==value parser
[3:35]	Babbage Linden:	sell it or give it away
[3:35]	Latif Khalifa:	Morg, they use snapshot that gets updated from time to time
[3:36]	Morgaine Dinova:	kk, tnx
[3:36]	Babbage Linden:	and then if lots of scripts use it on the same sim, they will share the memory use
[3:36]	Babbage Linden:	so, that's where we are will C#
[3:36]	Babbage Linden:	implementing the CoreCLR sandbox, upgrading to Mono 2.6.1 and designing the C# API
[3:37]	Babbage Linden:	there will be a few more details in my SL Pro talk later
[3:37]	Babbage Linden:	and in the talk I gave at FOSDEM
[3:37]	Babbage Linden:	the video of that talk should be online soon
[3:37]	Morgaine Dinova:	That's cool stuff. Stay away from Silverlight stuff that isn't in ECMA though, as it will result in much handw
[3:37]	Babbage Linden:	and the slides are currently here
[3:37]	Morgaine Dinova:	handwringing
[3:37]	Babbage Linden:	http://www.slideshare.net/JimPurbrick/building-the-virtual-babel-mono-in-second-life
[3:38]	Babbage Linden:	yes, good point Morgaine, I will look in to the ECMA standardisation of the libraries
[3:38]	Babbage Linden:	and will try to keep as close to LibOMV and opensim as I can
[3:38]	Babbage Linden:	whenever it makes sense
[3:39]	Babbage Linden:	so, next up, script usage
[3:39]	Latif Khalifa:	cool :) feel free to ping me if you have any questions about our implemenation of sl primitive types
[3:39]	Babbage Linden:	we are shipping the final code for exposing script memory and URL use in server 1.38
[3:39]	Babbage Linden:	once that's shipped we will start granting the caps to vewier 2
[3:40]	Babbage Linden:	and the script usage UI will appear
[3:40]	Babbage Linden:	it will be under about land>objects>script infor
[3:40]	Saijanai Kuhn:	still can't see videos in html media on a prim
[3:40]	Babbage Linden:	and the details you see will work in the same way as with prims
[3:40]	Saijanai Kuhn:	most of hte rest of you with SL 2 viewers can though
[3:40]	Xugu Madison:	(have to run, have a good morning everyone!)
[3:41]	Leia Lulu:	I would like to know what the proposed limits are
[3:41]	Leia Lulu:	per parcel
[3:41]	Babbage Linden:	if you're a region owner or estage manager you'll see all of the scripts in the region
[3:41]	Babbage Linden:	parcel owners will see scripts for all of their parcels
[3:41]	Babbage Linden:	everyone else will see summaries as with prims
[3:41]	Babbage Linden:	in this iteration, Mono scripts will show as using 64KB
[3:42]	Babbage Linden:	and LSL scripts will show as using 16KB of memory
[3:42]	Babbage Linden:	but, once we ship Small Scripts you'll be able to reserve less memory for Mono scripts
[3:42]	Leia Lulu:	will the limits be on memory usage or run time?
[3:42]	Latif Khalifa:	Babbage, it would be very useful if per object memory usage is expesed on edit object window in the same way primsa are done now, so a customer can checkout object for sale and see how much memory is used
[3:42]	Babbage Linden:	on average they only use 9KB
[3:43]	Babbage Linden:	hmm, nice point latif, I will mention it to jack
[3:43]	Latif Khalifa:	I'm afraid just having summary on the about land will not be sufficient
[3:43]	Imaze Rhiano:	Latif^2
[3:43]	Leia Lulu:	yes that is a very very good suggestion Latif
[3:43]	Becky Pippen:	What Latif said
[3:43]	Babbage Linden:	ok, good
[3:44]	Leia Lulu:	that stats will show memory usage then and not run time?
[3:44]	Qie Niangao:	can scripts increase their memory use dynamically, though?
[3:44]	Babbage Linden:	the first iteration of script usage is intended to get exactly this kind of feedback
[3:44]	Babbage Linden:	we want everyone to be comfortable with it before we start doing any enforcement
[3:44]	Babbage Linden:	qie, scripts will be able to change their reserved memory size at run time
[3:45]	Babbage Linden:	(if they're running on Mono)
[3:45]	Babbage Linden:	so if you have a simple door script you might reserve 4KB
[3:45]	Babbage Linden:	if you need to parse XML from a web service you might reserve 1MB
[3:45]	Babbage Linden:	so, shared media
[3:45]	Qie Niangao:	okay, so... Latif's suggestion won't reflect that dynamic usage potential, right?
[3:46]	Imaze Rhiano:	would it also possible to get more accurate tools that allow us to monitor script memory usage when developing scripts - beyond llGetFreeMemory?
[3:46]	Qie Niangao:	(I mean, I sell scripted object X, which shows w/ 4KB script usage, that bloats to 64K in use)
[3:46]	Latif Khalifa:	Qie, as far as I understand, script memory usage reservation will be on compile time, and not a function you call
[3:46]	Morgaine Dinova:	This reservation stuff, it's not going to be manual, is it? Harks back some 50 years, when you had to state how much stack you wanted manually.
[3:47]	Leia Lulu:	LOL
[3:47]	Qie Niangao:	that's why I asked..."[03:45] Babbage Linden: qie, scripts will be able to change their reserved memory size at run time"
[3:47]	Babbage Linden:	qie, in practice i think few scripts will dynamically change memory usage, because people will want to know how much they need up front
[3:47]	Latif Khalifa:	ah, then my understanding was flawed xD
[3:47]	Qie Niangao:	hehehe... okay. nevermind.
[3:47]	Babbage Linden:	as people will want to set up land, and leave it, expecting their scripts to keep running
[3:48]	Babbage Linden:	but, we'll have to see
[3:48]	Babbage Linden:	there is also the interesting question of what happens when a script runs out of memory
[3:48]	Babbage Linden:	LSO scripts will just stack/heap collide as normal
[3:48]	Babbage Linden:	Mono scripts _could_ potentially just reserve more memory if it's available
[3:49]	Babbage Linden:	but I don't know if that's a good thing or not
[3:49]	Babbage Linden:	I'd like to know what your thoughts are
[3:49]	Chaley May:	it has to be a good thing otherwise people will be forced to use another script to set active when they need
[3:49]	Chaley May:	just means more to do
[3:49]	Latif Khalifa:	dynamic changing of memory usage has a bad side effect on land owner's not knowing how many objects they can have
[3:50]	Babbage Linden:	right
[3:50]	Babbage Linden:	people are used to getting an X prim object
[3:50]	Chaley May:	if people have to send all this large amount of information through link messages your going to have problems
[3:50]	Babbage Linden:	but, that X prim object could always dynamically rez more prims...
[3:50]	Jonathan Yap:	I could see dynamic changing being useful during development--you start out small and see what amount of memory the finished script needs
[3:50]	Latif Khalifa:	so if I buy object A thinking it uses 512k and then it jumps to 4mb on me without knowing, and I am unable to rez more scripts, it would create WTF factor
[3:50]	Babbage Linden:	latif, exactly
[3:50]	Latif Khalifa:	Babbagem rezzed prims are easy to see
[3:51]	Babbage Linden:	so, do we need to enforce that in the platform?
[3:51]	Babbage Linden:	or will people just end up avoiding bloaty objects?
[3:51]	Latif Khalifa:	it's a tough one to call xD
[3:51]	Qie Niangao:	do parcels have a setting that allows/disables dynamic memory allocation?
[3:51]	Imaze Rhiano:	dynamic changing of memory could be object property - owner could then disallow scripts in object to allocate memory - or maybe set quota for them
[3:52]	Babbage Linden:	qie, not right now
[3:52]	Qie Niangao:	I meant as an option for future, but Imaze is probably better: per object, not per parcel
[3:52]	Morgaine Dinova:	I suggest that automatic acquiring of as much memory as needed be used, but allow people to set a limit above which auto allocation is blocked. That would force heavy users to think, but still provide a friendly environment for everyone else.
[3:52]	Babbage Linden:	this is an excellent discussion of the corder cases
[3:52]	Babbage Linden:	corner cases
[3:52]	Chaley May:	when creators make scripts and sell them they should be encouraged to start advertising how much memory they use
[3:52]	Babbage Linden:	I'll make sure gisele and jack see it
[3:53]	Chaley May:	otherwise we wont know until after we buy a script if we can use it
[3:53]	Babbage Linden:	chaley, yes, I think that will happen
[3:53]	Babbage Linden:	again, how much needs to be in the platform?
[3:53]	Babbage Linden:	memory use information in xstreet?
[3:53]	Babbage Linden:	something else?
[3:54]	Latif Khalifa:	I think current memory usage on edit window is crucial, as it will cover 90%+ cases where scripts will not dynamically use more methinks
[3:54]	Imaze Rhiano:	object memory usage when editing object - and - maybe allow to set maximal memory allocations for objects
[3:55]	Leia Lulu:	I do not think memory usage atttacks the issue of the overuse of scripts in sl. It sounds like memory usage will be limited, but there has been no talk on limiting runtime. A small script using little memory can cause a lot of runtime with a few functions
[3:55]	Chaley May:	we need to be able to see memory usage while in inventory i believe
[3:56]	Babbage Linden:	ok, we only have a few minutes left
[3:56]	Babbage Linden:	so, last topic, shared media
[3:56]	Babbage Linden:	as you saw, the documentation is here http://wiki.secondlife.com/wiki/LlSetPrimMediaParams
[3:56]	Babbage Linden:	unfortunately most of the shared media work was done before efficient scripts
[3:56]	Morgaine Dinova:	It's a general problem with inventory though, that no metadata is visible for anything. Big weakness of inventory model.
[3:56]	Babbage Linden:	so we may have to do an extra pass here to add the shared media params to the efficient scripts project
[3:57]	Babbage Linden:	but that should be OK
[3:57]	Leia Lulu:	I agree about the weakness in inventory
[3:57]	Babbage Linden:	morgaine, I agree, the lack of metadata on inventory and assets is a big problem
[3:57]	Babbage Linden:	there are various projects working on that
[3:58]	Chaley May:	oops
[3:58]	Babbage Linden:	but they're not my projects, so I'm not going to talk about them ;-)
[3:58]	Latif Khalifa:	those functionos are lacking in the permissions department, also inability to specify no toolbar is missing
[3:59]	Babbage Linden:	ok, 1 minute left
[3:59]	Morgaine Dinova:	Babbage: cool, that could be very worthwhile. Those groups need to liase with VWRAP though, because metadata is going to be accessible by protocol.
[3:59]	Babbage Linden:	is someone going to post the transcript to the wiki?
[3:59]	Leia Lulu:	Is the runtime going to be limited? or just memory usage?
[3:59]	Nock Forager:	ah I will.
[3:59]	Babbage Linden:	thanks nock
[3:59]	Morgaine Dinova:	Thanks Nock
[4:00]	Babbage Linden:	leia, memory first, hopefully CPU later
[4:00]	Babbage Linden:	CPU is actually less of a problem as it is limited per frame already
[4:00]	Babbage Linden:	whereas memory is currently unbounded
[4:00]	Leia Lulu:	so the projected date to have a fair share sim is years down the line then ?
[4:00]	Latif Khalifa:	yeah, i guess swapping on memory overusage is what kills sim performance the most
[4:00]	Babbage Linden:	ok, 4AM
[4:00]	Morgaine Dinova:	Babbage: is there a video of your SL Pro! talk, or just those slides?
[4:00]	Chaley May:	i thought each sim has its own cpu
[4:01]	Chaley May:	i mean core
[4:01]	Babbage Linden:	last thing: http://jira.secondlife.com/browse/SVC-3895
[4:01]	Chaley May:	so is not affecting others
[4:01]	Babbage Linden:	lots of changes are going in to 1.38 for this
[4:01]	Leia Lulu:	fair share usage in the SIM ?
[4:01]	Babbage Linden:	so only the first rez of an assembly stalls the sim
[4:01]	Leia Lulu:	and now it is going to cloud computing
[4:01]	Babbage Linden:	I'm working with the mono folks to see if we can get that stall to go away
[4:02]	Babbage Linden:	but we may have to wait for Mono 2.6.x to get rid of all the stalls
[4:02]	Babbage Linden:	in the meantime the changes in 1.38 will make a big difference
[4:02]	Chaley May:	i see limits and think it all means that not everyone will use what they are entitled to so a lot of resources go unused
[4:02]	Babbage Linden:	it also increases the amount of assemblies cached in each sim
[4:02]	Babbage Linden:	so, the chances that an assembly needs to be loaded for the first time are much lower too
[4:03]	Latif Khalifa:	mono 2.6.x has much improved garbage collector, some of my apps that were slowly leaking memory seem to have been cured with 2.6
[4:03]	Babbage Linden:	great news latif :-D
[4:03]	Babbage Linden:	ok, I should go an write an SL Pro talk
[4:03]	Babbage Linden:	thanks for coming everyone!
[4:03]	Jonathan Yap:	Thank you Babbage
[4:03]	Latif Khalifa:	Take care Babbage :)
[4:03]	Imaze Rhiano:	thanks Babbie
[4:03]	Cerdita Piek:	Thanks, Babbage. Take care :)
[4:03]	Qie Niangao:	thanks Babbage.
[4:03]	Becky Pippen:	thanks Babbage
[4:03]	Sahkolihaa Contepomi:	See you Babbage.
[4:03]	Morgaine Dinova:	Latif: great news! I hope the Opensim peepes test that soon. Linux is very second rate on that currently with 2.4 Mono
[4:04]	Chaley May:	bye