User:Babbage Linden/Office Hours/2009 12 02

Transcript

[3:17]	Babbage Linden:	hello!
[3:17]	Babbage Linden:	sorry I'm late :-(
[3:17]	Cerdita Piek:	hello babagge
[3:17]	Patnad Babii:	hi Babbage ㋡
[3:17]	Ardy Lay:	Hello Babbage
[3:17]	Sebastean Steamweaver:	Hey Babbage
[3:17]	Babbage Linden:	was working on c# with karel and didn't see the time :-)
[3:17]	Liandra Ceawlin:	You missed the cookies and coffee. We consumed it all already. ;(
[3:17]	Kaluura Boa:	hehehe
[3:17]
[3:17]	Liandra Ceawlin:	Hello, Cog!
[3:18]	Patnad Babii:	interesting what kind of c# project were you working on
[3:18]	Patnad Babii:	something top secret eh... ^^
[3:18]	Babbage Linden:	there, that's better
[3:18]	Babbage Linden:	no, not at all
[3:19]	Babbage Linden:	i've been talking about it at these office hours for years :-D
[3:19]	Babbage Linden:	we have a prototype of c# support in the simulator
[3:19]	Patnad Babii:	oh is it that project to program prims with C# ?
[3:19]	Babbage Linden:	that let's you author scripts in c# instead of lsl
[3:19]	Patnad Babii:	:):)
[3:20]	Babbage Linden:	we're getting the prototype ready for internal evaluation at linden lab
[3:20]	Patnad Babii:	i like
[3:20]	Liandra Ceawlin:	Groovy. =:O
[3:20]	Babbage Linden:	which will hopefully happen this week
[3:20]	Babbage Linden:	i'm hoping to get lots of useful feedback on the api
[3:20]	Patnad Babii:	nothing open to the public yet right
[3:20]	Babbage Linden:	and bug reports that we can fix before we do a public preview
[3:20]	Babbage Linden:	not yet, but hopefully soon
[3:20]	Imaze Rhiano:	yay!
[3:21]	Patnad Babii:	thats a good news ㋡
[3:21]	Babbage Linden:	kelly has been enjoying playing with it this week
[3:21]	Patnad Babii:	will there be any sample code you'll be offering to play with
[3:21]	Babbage Linden:	in other news, i've been relentlessly tracking down the sim freeze problem with mono scripts
[3:21]	Sebastean Steamweaver:	Excellent news babbage :)
[3:22]	Babbage Linden:	i've narrowed it down to System.Reflection.Assembly::Load(byte[])
[3:23]	Babbage Linden:	which under some circumstances is taking 19ms
[3:23]	Babbage Linden:	which becomes a big problem when you have 22ms per frame
[3:23]	Babbage Linden:	and you want to load 100s of scripts in a single frame when people turn up with prim hair with resize scripts attached
[3:23]	Sebastean Steamweaver:	Babbage, any chance of us being able to review the public APIs?
[3:23]	Babbage Linden:	most of the implementation of System.Reflection.Assembly::Load(byte[]) is in unmanaged code in the mono runtime
[3:24]	Babbage Linden:	so I need to go back to profiling unmanaged code again
[3:24]	Babbage Linden:	but I'm working with the mono team now
[3:24]	Babbage Linden:	so I'm hopeful that I'll get it fixed soon
[3:25]	Babbage Linden:	I'm also talking about when we're going to implement multithreaded object rezzing in the simulator
[3:25]	Babbage Linden:	which will avoid the simulator stalling on object rez
[3:25]	Babbage Linden:	hopefully that will happen early next year
[3:26]	Sebastean Steamweaver:	Any progress on the script efficiency front?
[3:26]	Babbage Linden:	Sebastean, I definitely want to get public review of the C# apli
[3:26]	Babbage Linden:	as soon as possible after we have our internal tests
[3:26]	Sebastean Steamweaver:	:D
[3:26]	Patnad Babii:	is the code editor in viewer will change at all once you have c# support
[3:27]	Patnad Babii:	any kind of intellisense maybe ? ㋡
[3:27]	Babbage Linden:	on the efficient scripts front our current favourite plan is to add llSetPrimitiveParamsNoDelay and llGetPrimitiveParams
[3:27]	LSL Scientist:	<3
[3:27]	Babbage Linden:	and add support for setting text to both functions
[3:28]	Kaluura Boa:	Niiiice!
[3:28]	Babbage Linden:	I think that will cover most of the common cases where many scripts are currently required
[3:28]	Sebastean Steamweaver:	Any chance of getting a function like llSetLinkListPP?
[3:28]	LSL Scientist:	that would be awesome too
[3:28]	Babbage Linden:	although I'd still like to hear any other examples of cases where you need to use many scripts and shouldn't have to
[3:29]	LSL Scientist:	we need more mem
[3:29]	Babbage Linden:	I really don't like llSetLinkListPP as it's a fudge around the lack of a proper scene graph heirarchy
[3:29]	Babbage Linden:	I'd prefer to allow linksets to contain linksets
[3:29]	Sebastean Steamweaver:	Is there an alternate method of avoiding lots of loops?
[3:29]	Babbage Linden:	like a proper scene graph
[3:29]	Kaluura Boa:	Hierchical linking! Wow!
[3:30]	Kaluura Boa:	Hierarchical*
[3:30]	Babbage Linden:	Sebastean, at the moment the goal is to allow loops instead of many scripts ;-)
[3:30]	Babbage Linden:	so, we're planning to start working on efficient scripts soon
[3:31]	Babbage Linden:	while the internal c# beta is happening
[3:31]	Sebastean Steamweaver:	Well, loops instead of many scripts is good, and an improvement, yes :) I was told that loops increase script time though.
[3:31]	LSL Scientist:	also some good system to do grid wide prim to prim communication would be cool, the current methods are too limited(slow) and to beat the current limits we must do so horrible things i dont even want to mention them
[3:31]	Babbage Linden:	then work on c# after we've done efficient scripts
[3:31]	Liandra Ceawlin:	I can't see any difference between sending a link message to every prim individually and using LINK_SET. I suspect that LINK_SET uses a loop internally anyway. >_>
[3:32]	Sierra Janus:	Can't wait to see these APIs though
[3:32]	Patnad Babii:	LSL: have you concider the http-in option for that its working good for my projects ^^
[3:32]	Babbage Linden:	Liandra, the problem is that you need to have hundreds of scripts listening for the link messages than then operating on their prim
[3:32]	Liandra Ceawlin:	Or that the loop overhead is just totally negligible.
[3:33]	Liandra Ceawlin:	I mean, just in response to the loop avoidance percieved efficiency thing.
[3:33]	Babbage Linden:	if you can just loop through the prims getting and setting their parameters then you can avoid many scripts
[3:33]	LSL Scientist:	http-in had potential, but the non-stable address makes it pretty useless, i wish we could just use the key of the prim like with e-mail
[3:33]	Babbage Linden:	which is an issue if you have limited script memory ;-)
[3:33]	Sebastean Steamweaver:	Well Liandra, the one I was told that by was Simon linden.
[3:34]	Babbage Linden:	LSL Scientist, non-stable addresses is one of the major improvements of http-in ;-)
[3:34]	Kaluura Boa:	It forces us to go through hoops to keep a stable address...
[3:34]	Sebastean Steamweaver:	He had been doing some research into loops and how they affected the script time. I guess to me, it seems odd that we can set one link, or all links, or all links but one, but we can't set a specific group. And heirarchical linking, as wonderful as it sounds, is a long, long ways down the road.
[3:34]	Babbage Linden:	the email routing bottleneck was a problem
[3:35]	Babbage Linden:	now you can use an external web host to do the routing
[3:35]	Babbage Linden:	just have http://mydomain.com/myscript
[3:35]	Babbage Linden:	redirect to whatever the current URL for your script is
[3:35]	Sierra Janus:	What's happening with the issue of persistant memory other then primitive descriptions?
[3:36]	Patnad Babii:	thats true there is even example on the wiki for that
[3:36]	Babbage Linden:	and have your script tell http://mydomain.com whenever its URL changes
[3:36]	Babbage Linden:	patnad, not sure
[3:36]	LSL Scientist:	non stable address makes me need to send e-mail to the prim every time it cross region border to get the new http address, and im back to where i started,
[3:36]	Babbage Linden:	I was going to implement a simple django service for it and make it open source
[3:36]	Babbage Linden:	i should get round to it
[3:36]	Patnad Babii:	yes i seen some example using a certain google technology
[3:36]	Babbage Linden:	LSL Scientist, no you're not
[3:37]	Babbage Linden:	you can use http-out to tell the world the new URL
[3:37]	Babbage Linden:	and you can avoid (slow, busted) email altogether
[3:38]	Liandra Ceawlin:	I've got a public object URL lookup service running on appengine, but nobody uses it. :< Lol.
[3:38]	Babbage Linden:	did anyone do any testing of the TCMalloc regions on aditi in the end?
[3:38]	Babbage Linden:	there you go LSL Scientist, use Liandra's service ;-)
[3:39]	LSL Scientist:	yea, true, i could have separate nonmoving prim to control the address that changes 3 times a second, now need to wait LL to make up their mind if they will limit it more untill i can start using it
[3:40]	Babbage Linden:	I think you have everything you need ;-)
[3:40]	Babbage Linden:	so, TCMalloc testing? anyone?
[3:40]	Babbage Linden:	notice anything interesting?
[3:40]	Sebastean Steamweaver:	We were . . . kinda sorta told about that.
[3:41]	Babbage Linden:	(apart from the attachments stopping on region entry, which was a bug in trunk that we picked up)
[3:41]	Sebastean Steamweaver:	I think it was mentioned at Andrew's office hours.
[3:41]	Babbage Linden:	we talked about it here for a few weeks
[3:41]	Babbage Linden:	and even had the office hour on aditi last week
[3:41]	Sebastean Steamweaver:	Ahh, I haven't been able to attend these hours for a while.
[3:41]	Sebastean Steamweaver:	I probably missed it.
[3:41]	Babbage Linden:	i was hoping people would have a play and let me know what the performance was like
[3:42]	Babbage Linden:	ok, well anyway, this week those regions are going to be replaced with copies of regions from agni
[3:42]	Cerdita Piek:	i was on those regions, but i did not know what to test
[3:42]	Babbage Linden:	so that the region owners can compare the performance
[3:42]	Babbage Linden:	I wanted to tell you today in case you wanted to do more testing
[3:42]	Babbage Linden:	but it doesn't sound like that will be a problem
[3:44]	Ardy Lay:	I didn't really notice any differences when rezzing objects with scripts in them.
[3:44]	Babbage Linden:	ok, great, thanks ardy
[3:44]	Babbage Linden:	i don't expect TCMalloc will provide any huge performance boost
[3:45]	Babbage Linden:	but it will allow us to profile memory use
[3:45]	Cerdita Piek:	i also tested some attachments and a few objects, but as i was alone and in a region with 0 prims, everything seemed to work perfect
[3:45]	Babbage Linden:	which will let us tackle sim swapping and then leg
[3:45]	Babbage Linden:	lag, even
[3:45]	Ardy Lay:	I have a stack of 990 prims with one script each that I was playing with.
[3:45]	Sierra Janus:	So in regards to the C# stuff, is there any real shift to OOP or is it still going to have a procedural feel to it? What about the FSM?
[3:46]	Babbage Linden:	Cerdita, right, that's why the next step is to test with big heavy regions copied from the main region
[3:46]	Babbage Linden:	Sierra, the event interface is OO and very .NET idiomatic
[3:47]	Babbage Linden:	to author a script you subclass LindenLab.SecondLife.Script
[3:47]	Babbage Linden:	and then override methods like OnTouchStart
[3:47]	Babbage Linden:	or alternatively register methods with delegates
[3:47]	Sierra Janus:	Oh good, I was fearing some procedural muck being slapped onto it
[3:47]	Babbage Linden:	TouchStart = new TouchStartDelegate(MyFunction)
[3:48]	Babbage Linden:	the latter allows you to dynamically set event handlers
[3:48]	Becky Pippen:	very cool
[3:48]	Sierra Janus:	Work with the system not against it :) Hurray
[3:48]	Babbage Linden:	which allows you to control UI elements like the "Pay..." menu
[3:49]	Babbage Linden:	the goal is to make it very comfortable for existing C# developers
[3:49]	Babbage Linden:	and so it uses .NET idioms wherever possible
[3:49]	Sierra Janus:	In terms of instance attributes, is more data available to read and write compared to LSL now?
[3:49]	Liandra Ceawlin:	o/
[3:49]	Babbage Linden:	the library calls are still flat and procedural
[3:49]	Babbage Linden:	LindenLab.SecondLife.Library.llSay calls the same method that you're used to
[3:50]	Sierra Janus:	Oh so no myPrim.Description = "Hurray!";
[3:50]	Sierra Janus:	?
[3:50]	Babbage Linden:	but, as you can define your own types you can build OO interfaces on top
[3:50]	Babbage Linden:	so, I have an example which defines a LinkedPrim class
[3:50]	Babbage Linden:	which remembers it's index
[3:51]	Babbage Linden:	it has a SetTexture(face) method
[3:51]	Sierra Janus:	Aha, so it does :D
[3:51]	Babbage Linden:	that passes the face and it's index to the low level LindenLab.SecondLife.Library API
[3:52]	Sierra Janus:	What stuff shouldn't we expect that we can do now with C#/.NET?
[3:52]	Babbage Linden:	the plan is to keep the API procedural so it can be used by both C# and LSL, but to allow authoring of OO APIs on top in C#
[3:52]	Babbage Linden:	you won't have access to all the .NET framework
[3:52]	Babbage Linden:	we will be using the Moonlight machinery to define a subset that usable
[3:53]	Babbage Linden:	but hopefully that will include things like System.Collections
[3:53]	Babbage Linden:	so you'll have access to maps, stacks, lists etc
[3:53]	Sierra Janus:	Oh good! I was fearing you might say "Oh, an no fancy collections..... muahahahahahaha!" :P
[3:53]	Sierra Janus:	and no*
[3:53]	Babbage Linden:	also, we're not sure we're going to be able to support generics, but we'll see
[3:54]	Babbage Linden:	right, 5 minutes left
[3:54]	Babbage Linden:	any more questions?
[3:55]	Aimee Trescothick:	yep, what happened in the last 55 that I missed :D
[3:55]	Aimee Trescothick:	just kidding :)
[3:55]	Patnad Babii:	Babbage, any chance the viewer can support some kind of intellisense
[3:55]	Sebastean Steamweaver:	Any chance the script editor in the viewer will be made . . . more functional? :)
[3:55]	Babbage Linden:	hi aimee
[3:55]	Aimee Trescothick:	hi :)
[3:55]	Babbage Linden:	the log will be online soo
[3:55]	Babbage Linden:	n
[3:55]	Aimee Trescothick:	:)
[3:56]	Babbage Linden:	Sebastean, that's currently in discussion
[3:56]	Sebastean Steamweaver:	Also, any word on user-created/shared libaries/closed APIs?
[3:56]	Imaze Rhiano:	debuggin functionality would be super
[3:56]	Sierra Janus:	Imaze++
[3:56]	Babbage Linden:	I'd like to expose an API that would let you use visual studio (express) or monodevelop and have that wired in to the viewer or upload capability
[3:57]	Babbage Linden:	ideally you'd be able to to create a new second life script project and have that set up a test harness that you could use for developing/testing/debugging
[3:57]	Babbage Linden:	and then have a button to upload to SL
[3:57]	Babbage Linden:	it's unlikely that we'll be able to allow the debugging of untrusted code in our servers
[3:57]	Babbage Linden:	so debugging will have to take place in an IDE
[3:58]	Babbage Linden:	but we can make the integration with the IDE much better#
[3:58]	Sebastean Steamweaver:	I can live with that, but better highlighting, fixing the undo, autocomplete, things like that, would make life much easier.
[3:59]	Babbage Linden:	Sebastean, user created, sharable, libraries is on the roadmap, but not in the currently funded part right now
[3:59]	Sierra Janus:	This is kind of minor I suppose, but what about marshalling/serialisation of data between scripts? Or would that be done at our level?
[3:59]	Babbage Linden:	i'd really like to be able to call Xylor.Text.Set("Foo") instead of passing link messages around
[3:59]	Liandra Ceawlin:	As far as IDEs go, I personally would rather see a way to insert scripts into the sim independently of the viewer. Think: Auto upload from eclipse, and auto-update from subversion. >_>
[4:00]	Babbage Linden:	or Ordinal.Twitter.SetStatus("I'm an LSL script at " + slurl);
[4:00]	Babbage Linden:	so hopefully we'll get to that
[4:00]	Babbage Linden:	Liandra, right, I'd like to get us out of the IDE development business as well as the language design business
[4:01]	Liandra Ceawlin:	Lol
[4:01]	Babbage Linden:	(as neither of them are the virtual worlds business)
[4:01]	Babbage Linden:	ok, times up, I need to run
[4:01]	Babbage Linden:	thanks for coming
[4:01]	Babbage Linden:	and hopefully see you next week
[4:01]	Sierra Janus:	Thank you Babbage :)
[4:01]	Becky Pippen:	thanks Babbage!
[4:01]	Patnad Babii:	pretty cool Babbage you have a nice day ㋡
[4:01]	Cerdita Piek:	Thank you, take care, Babbage :)
[4:02]	Sebastean Steamweaver:	Have a good night Babbage
[4:02]	Sebastean Steamweaver:	da*
[4:02]	Sebastean Steamweaver:	y
[4:02]	Sierra Janus:	Btw Patnad, shouldn't you be wearing a MSVS 2010 t-shirt not a 2008?....
[4:02]	Sierra Janus:	Oh he left
[4:02]	Kaluura Boa:	One last question... ETA for C#?
[4:02]	Sierra Janus:	-till beta
[4:03]	Babbage Linden:	mid 2010 hopefully
[4:03]	Babbage Linden:	see you all next week!

Generated with SLog Wikifier