User:Zero Linden/Office Hours/2007 Aug 09

Transcript of Zero Linden's office hours:

[8:04]	Zero Linden:	oy - i'm in!
[8:04]	Babbage Linden:	ok, good, i've managed to sit
[8:04]	Zero Linden:	Oy!
[8:04]	Dr Scofield:	hi zero
[8:04]	Babbage Linden:	and here's zero
[8:04]	Tree Kyomoon:	yay zero!
[8:04]	Zero Linden:	It only too 40min. to log in!
[8:05]	Gale Barzane:	hi zero
[8:05]	Tedd Maa:	ehlo
[8:05]	Saijanai Kuhn:	yo zero
[8:05]	Dr Scofield:	wow that was quick :-)
[8:05]	Saijanai Kuhn:	had yer coffee yet?
[8:05]	Tree Kyomoon cant believe that on my crappy satellight connection way out in the middle of no where I was the first one here :)
[8:05]	Zero Linden:	yes
[8:05]	Tedd Maa:	we've been discussing a bit about Mono in your absence
[8:05]	Zero Linden:	I've got coffee
[8:05]	Babbage Linden:	oh, great
[8:06]	Dr Scofield:	tree: sat up and downlink?
[8:06]	Babbage Linden:	where did you get to?
[8:06]	Saijanai Kuhn:	pretending to discuss...
[8:06]	Gale Barzane:	hahah tree do i get points for 2nd place
[8:06]	Tree Kyomoon:	yes high speed up and down
[8:06]	Tree Kyomoon:	via telesat
[8:06]	Dr Scofield:	cool!
[8:06]	Tedd Maa:	think we were discussing where compile would happen and some recompile of all LSL scripts
[8:06]	Dr Scofield:	what is the bandwidth?
[8:06]	Babbage Linden:	good topics
[8:06]	Tree Kyomoon:	500k up and 1.5mb down
[8:06]	Dr Scofield:	not bad
[8:06]	Zha Ewry:	A coffee plentiful Ruthe'd Zero
[8:06]	Babbage Linden:	compilation now happens via a web service on Branch_MONO
[8:07]	Zero Linden:	tree - but surely the latency is high?
[8:07]	Babbage Linden:	source is uploaded using the new asset upload framework
[8:07]	Tree Kyomoon:	but theres a 2000 ms lag, thanks to that pesky slow speed of light...damn physics
[8:07]	Tedd Maa:	it is a straight LSL->.Net Assembly compile?
[8:07]	Babbage Linden:	and the target specified as a parameter
[8:07]	Dr Scofield thinks it must be, remembers working via satellite from munich to berkeley
[8:07]	Babbage Linden:	the service either compiles to LSL2 bytecode
[8:07]	Babbage Linden:	or to CIL assembler
[8:08]	Tedd Maa:	ok, is this how it works today or how it will work?
[8:08]	Dr Scofield:	babbage, do you do byte code checking?
[8:08]	Babbage Linden:	which is then assembled to a CLI assembly
[8:08]	Tree Kyomoon:	so I would like to know if, when Mono is enabled, I'll be able to type C++ code into any LSL script window?
[8:08]	Babbage Linden:	which then has microtheads injected
[8:08]	Babbage Linden:	this is how Branch_MONO works today
[8:08]	Dr Scofield:	and then blows up?
[8:08]	Babbage Linden:	to VM targets
[8:08]	Babbage Linden:	LSL2 or Mono
[8:08]	Tedd Maa:	will servers be running both LSL2 and Mono VM's?
[8:09]	Gale Barzane:	brb coffee refill
[8:09]	Babbage Linden:	once the service has done the compilation etc it saves the bytecode or assembly
[8:09]	Babbage Linden:	which then is ressed by the sim
[8:09]	Tedd Maa:	so the .Net assembly is never actually at the client?
[8:09]	Babbage Linden:	which contains both the LSL2 and Mono VMs
[8:09]	Babbage Linden:	the assembly is never on the client
[8:09]	Babbage Linden:	only the source is on the client
[8:09]	Saijanai Kuhn:	ah.
[8:09]	Dr Scofield:	do you envision allowing byte code uploads?
[8:09]	Babbage Linden:	yes, once mono has a bytecode verifier
[8:10]	Babbage Linden:	(which they are working on for Moonlight)
[8:10]	Tedd Maa:	what do you mean by that?
[8:10]	Tedd Maa:	(bytecode verifier - what do you need to verify?)
[8:10]	Babbage Linden:	we will look in to allowing assembly uploads which we can verify and then res
[8:10]	Dr Scofield:	verify that the code is not doing anything nasty
[8:10]	Zero Linden:	well, that, and we have a bytecode injector that works on pre-compiled bytecode
[8:10]	Babbage Linden:	you need to verify that the assembly will not corrupt memory
[8:11]	Babbage Linden:	or corrupt object identity
[8:11]	Tedd Maa:	AppDomains can not restrict that?
[8:11]	Zha Ewry:	Which, of course, is, halting equivalent problem.
[8:11]	Dr Scofield:	which is, of course, easy
[8:11]	Zero Linden thinks: "silly CIL/CLR, not guaranteed memory safe...."
[8:11]	Babbage Linden:	no, appdomains can have CAS security policies, which restrict the methods scripts can call
[8:11]	Zha Ewry:	You can do some things.. in terms of verifying what it accesses
[8:12]	Babbage Linden:	java bytecode also needs to be verified
[8:12]	Babbage Linden:	if you don't trust it
[8:12]	Zha Ewry:	Right.. And again.. There are limits to what you can validate..
[8:12]	Zero Linden:	Zha - for Java bytecord and for CIL, the verification is just enough shy of the halting problem to be doable
[8:12]	Saijanai Kuhn contemplates, newer, higher tech greifing vehicle
[8:12]	Tedd Maa:	correct me if I'm wrong, but AppDomains is THE security function used by say for example IE executing .Net executables over the web - how does this differ?
[8:13]	Dr Scofield:	is that in the mono engine as well?
[8:13]	Babbage Linden:	even with appdomain security you can build an assembly which pushes an int and pops a string
[8:13]	Zha Ewry:	Well.. if you want to make sure it doesn't touch memory it shouldn't yes.. within reason.
[8:13]	Babbage Linden:	corrupting memory and so becoming insecure
[8:13]	Babbage Linden:	the verification checks the typesafety of the stack for all control flows
[8:14]	Tedd Maa:	I see, so with a managed stack it would solve the problem? that brings me to my next question actually
[8:14]	Saijanai Kuhn contemplates that this had better become open source real fast so more people will be working on security than on breaking it
[8:14]	Zha Ewry:	But.. I'd love to see a proof that as you look at more and more off the stack corrpition stuff, it doesn't become halting equiv.
[8:14]	Gale Barzane giggles.
[8:15]	Dr Scofield:	we really should solve this halting problem once and for all
[8:15]	Zero Linden:	Tedd - yes, one could implement a bytecode interpreter for Java or CIL that had typed data on the stack, and had all bytecodes check types.... but this would be harder to on-the-fly compile to native instructions
[8:15]	Babbage Linden:	there are limits to control flow to ensure that verification requres a single pass through the bytecode
[8:15]	Zha Ewry:	OHH.
[8:15]	Zha Ewry:	Ok.
[8:15]	Babbage Linden:	for example the stack needs to be empty on a backwards jump
[8:15]	Babbage Linden:	which doesn't affect turing completeness
[8:15]	Zha Ewry:	So. you can limit the number of total tuples ou need to examine
[8:15]	Babbage Linden:	and makes verification doable
[8:15]	Tree Kyomoon:	so...will I be able to type C++ into the script windows and be able to access all that power? (sorry if this is a dumb question)
[8:15]	Babbage Linden:	it an inductive process
[8:16]	Babbage Linden:	that just needs to be able to examine each bytecode once
[8:16]	Saijanai Kuhn:	as long as the C++ compiler doesn't do the forbidden stuff
[8:16]	Saijanai Kuhn:	by accident
[8:16]	Zero Linden:	Zha - it has been done - basically it is one of computing type-sets, and you can show that given a finite number of methods in the system, the type sets must settle
[8:16]	Dr Scofield:	tree: if you've got a C++-to-CIL compiler, yes
[8:16]	Tedd Maa:	In my implementation of LSL ByteCode to .Net Assembly I'm using managed stack to push/pop onto .Net stack for the microthreading. This is far from optimal in terms of speed, and not applicable if users upload their own data. Is the way to look at the stack you are using specific to Mono?
[8:16]	Babbage Linden:	managed C++ doesn't generate verifiable assemblies in all cases
[8:16]	Babbage Linden:	(when you're using pointer arithmetic)
[8:16]	Babbage Linden:	so, you'll need to use C#, VM, Python
[8:16]	Zha Ewry is still musing about the not turing complete changing comment
[8:16]	Tree Kyomoon:	so a C++ to CIL compiler wont come with the client?
[8:17]	Babbage Linden:	or be careful about the features you use
[8:17]	Tree Kyomoon:	will any compiler come with teh client?
[8:17]	Babbage Linden:	(you can always locally verify as a build step)
[8:17]	Dr Scofield thinks we should have a cobol-to-CIL compiler
[8:17]	Dr Scofield:	;-)
[8:17]	Saijanai Kuhn:	Smalltalk... Squeak Smalltalk
[8:17]	Tedd Maa:	Will .Net Assemblies use the same LSL-functions (ll*) as LSL?
[8:18]	Saijanai Kuhn:	not sure how compatible the VMs are though
[8:18]	Babbage Linden:	yes
[8:18]	Babbage Linden:	the ll* functions are exposed to the CIL
[8:18]	Zero Linden:	Sajanai- not at all
[8:18]	Tedd Maa:	When will we be able to see the first .Net sample script?
[8:18]	Saijanai Kuhn:	There's somone who has prted Smalltalk to mono. Just wondering what the performance hit is
[8:19]	Zha Ewry:	So.. all the langauges share the same CIL bindings into the SL functionality?
[8:19]	Babbage Linden:	i can blog it if you like todd
[8:19]	Tree Kyomoon:	what is CIL?
[8:19]	Saijanai Kuhn:	VM of mono
[8:19]	Tedd Maa:	would be really great
[8:19]	Dr Scofield:	babbage, please do!
[8:19]	Babbage Linden:	i've written some C# scripts that run in SL
[8:19]	Tree Kyomoon:	does CIL have its own native script?
[8:19]	Zero Linden:	The problem of languages like Smalltalk compiling to CIL is that things like booleans and integers need to be wrapped as objects
[8:20]	Zero Linden:	at which point the CIL bytecode for handling such things becomes unavailable
[8:20]	Babbage Linden:	CIL is an object oriented assembly language
[8:20]	Babbage Linden:	which .NET languages compile to
[8:20]	Saijanai Kuhn:	ahhhh. That would slow things down just a tad over the ST VM
[8:20]	Tree Kyomoon:	so we could write in CIL in the script windows?
[8:20]	Babbage Linden:	tree, potentially, yes
[8:20]	Zha Ewry:	Right, CIL pretty much wants to think the language is a algol derivitiive with C++ style OO
[8:20]	Zero Linden:	where as the Smalltalk VM has many carefully crafted... well, er, hacks (!) to make this reasonable
[8:20]	Zero Linden:	CIL doesn't
[8:20]	Saijanai Kuhn:	oh, goody another assembler to learn
[8:20]	Babbage Linden:	we assemble it anyway
[8:20]	Zha Ewry:	Not a TIL, or a pure message based OO language
[8:21]	Tedd Maa:	just a thought, but a decompile/recompile would act as a verifier?
[8:21]	Babbage Linden:	everything beyond compiling LSL to CIL and running it faster on Mono is speculation at this point
[8:21]	Babbage Linden:	tedd, no
[8:21]	Zero Linden:	and on-the-fly compilation is a bit more difficult with such a system .... though for the record, the first dynamic compilation system was done for Smalltalk, almost a decade before Java
[8:21]	Tedd Maa:	no, nevermind, I've managed to compile some really bad IL
[8:21]	Babbage Linden:	you can decompile and compile unsafe CIL
[8:21]	Zha Ewry:	LOL Tedd
[8:22]	Tree Kyomoon:	"CIL" is "C Intermediate Language" ?
[8:22]	Zha Ewry:	Right.. The issue isn't compilable.. it is whether what is compiled bends the typesafe rules of the stack and memory access
[8:22]	Babbage Linden:	(i contributed 400+ verification tests to Mono, they only worked because the mono assembler would accept unsafe CIL)
[8:22]	Saijanai Kuhn:	Someone with a linden labs email address said recently on sldev that eventually there would be a mono VM in the client and that this would be the blessed cinterpreter for scripting?
[8:23]	Babbage Linden:	if there were going to be a VM in the client I would like to see it be mono
[8:23]	Babbage Linden:	just for sanities sake
[8:23]	Zha Ewry:	Can't sell you on LUA?
[8:23]	Saijanai Kuhn:	eh, things like lua are designed to be drop-in scripting modules
[8:23]	Babbage Linden:	you might have been able to 2 years ago ;-)
[8:23]	Zha Ewry:	Well, right. But linked in there
[8:24]	Babbage Linden:	mono is designed to be embedded too
[8:24]	Saijanai Kuhn:	there's at least 3 people workign on clients with Lua scripting that I am aware of
[8:24]	Babbage Linden:	it might be nice to rally them around mono
[8:24]	Babbage Linden:	depending on where they've got to
[8:25]	Zha Ewry:	I see the sanity in keeping one language.. but Lua has a pretty good track record on this stuff...
[8:25]	Saijanai Kuhn:	gotta give them guarantees beyond "real soon now"
[8:25]	Zha Ewry:	RSN? It's a a industry complient TLA, what more do they want?
[8:25]	Tedd Maa:	has Mono given any signals on supporting microthreading by the way?
[8:25]	Saijanai Kuhn:	As long as it can do a rational subset of what the WoW scripting for the client allows, I'll go with anything
[8:25]	Tree Kyomoon:	so what language should we be learning in order to take best advantage of the Mono implementation?
[8:26]	Saijanai Kuhn:	LSL
[8:26]	Dr Scofield:	C#
[8:26]	Zero Linden:	LSL!
[8:26]	Saijanai Kuhn preens
[8:26]	Babbage Linden:	there is a stack blitting microthreading library for mono
[8:26]	Babbage Linden:	as well as my bytecode injection library
[8:26]	Zha Ewry:	Babbage.. once you get to runnign mono... is there a short list of features you'd expect to see in LSL, such as some decent associative structure?
[8:26]	Babbage Linden:	it would be nice to use blitting for scheduling
[8:26]	Tree Kyomoon:	yes, how will the Mono implementation change LSL?
[8:26]	Babbage Linden:	and just use the bytecode injection for thread serialisation on script migration
[8:27]	Babbage Linden:	but the first iteration will use bytecode injection for everything
[8:27]	Tree Kyomoon:	what new features, methods and functions will we see?
[8:27]	Babbage Linden:	if i'm really lucky in the first instance you'll just see scripts run faster
[8:27]	Zha Ewry:	Heh. And fairly little breakage due to changed timing
[8:28]	Saijanai Kuhn:	or a lot of breakage at first
[8:28]	Zero Linden:	remember that no matter what the language, or enhanced libraries, scripts in objects will always continue to have a rather different execution environment than normal coding
[8:28]	Zha Ewry:	But, one assumes, that once you get that done, there will be new stuff
[8:28]	Zero Linden:	for one, there will still be small scripts, and no shared memory
[8:28]	Babbage Linden:	i'd like to see new languages
[8:28]	Zero Linden:	there will be events (shoe horned into some langagues as needed)
[8:28]	Zha Ewry:	Right, Zero's been through why object scripts will be small (See posted transcripts)
[8:28]	Saijanai Kuhn:	will lists be rationalized?
[8:28]	Zero Linden:	there may or may not be states
[8:28]	Tree Kyomoon:	yes, like will we be able to expect real objects and arrays?
[8:28]	Zero Linden:	there will be a SMALL amount of memory
[8:29]	Zero Linden:	there will be no persistence beyond that memory built in
[8:29]	Tree Kyomoon:	and parent child relationships between in world objects?
[8:29]	Tedd Maa:	How are states handled when compiled from LSL?
[8:29]	Saijanai Kuhn:	if ilst functions or new replacements become more sane, memory will be much less an issue
[8:29]	Tedd Maa:	switch() ?
[8:29]	Babbage Linden:	i'd rather allow other languages instead of bolting arrays and objects on to LSL
[8:29]	Zero Linden:	Saijanai - I agree
[8:29]	Zero Linden:	rational lists, strings, arrays and maps will make the 16k limit be less of an issue
[8:29]	Zha Ewry:	Tree, the object/object question isn't really a LSL question, exacttly
[8:30]	Zero Linden:	but again, C++ may not be such a great choice -- it isn't like you're going to be able to have tons of classes and your disposal
[8:30]	Tree Kyomoon:	Babbage...if thats the case, then what language will be the best to take advantage of that kind of functionality?
[8:30]	Zero Linden:	erlang!
[8:30]	Saijanai Kuhn missed that one, for sure... erlang?
[8:31]	Zha Ewry:	well, Zero, i'm not sure that's entirely true.. Better assoitaive structures.. only help a little if you have room for your maps to run
[8:31]	Zero Linden:	(only half joking.... but the process and communication model of erlang is much closer to LSL & scripts in objects than anything I know of)
[8:31]	Babbage Linden:	C# is closest to the CIL
[8:31]	Babbage Linden:	I'd like to see python and the DLR work in SL
[8:31]	Babbage Linden:	but we'll see
[8:31]	Tree Kyomoon likes using objects and arrays...they are more efficient than lists
[8:31]	Zero Linden:	Zha - I'm pretty sure that an associate structure supported by the languge is going to take less memory than they one I build with lists in LSL today.
[8:31]	Zha Ewry:	Oh, sure.
[8:31]	Saijanai Kuhn:	at least add arrays while new languages are readied...
[8:31]	Dr Scofield:	true
[8:31]	Zha Ewry:	But 16K is still tiny
[8:32]	Zero Linden:	though mind you, it won't be enough to let one code with abandon like one does with most scripting languages...
[8:32]	Babbage Linden:	allowing CIL as a first new language is a nice idea
[8:32]	Tree Kyomoon:	does CIL have arrays?
[8:32]	Babbage Linden:	as it would allow objects and arrays without the hassle of extra compilers
[8:32]	Tree Kyomoon:	ah ok good, that would be excellent
[8:32]	Tree Kyomoon needs to learn CIL asap
[8:32]	Saijanai Kuhn:	its designed for C# it better have something related to objects and arrays
[8:33]	Babbage Linden:	again, allowing CIL is speculation
[8:33]	Zero Linden:	and I'm pretty sure strings in CIL will take less memory than the current LSL VM implemetnation
[8:33]	Saijanai Kuhn:	another thing we need in LSL: better string handling.
[8:33]	Saijanai Kuhn:	yes, its a bandaid
[8:33]	Tedd Maa:	PEverifier.exe is the kind of verification Mono is implementing?
[8:33]	Babbage Linden:	at the moment we whitelist just the opcodes needed by the LSL to CIL compiler
[8:33]	Zero Linden:	I vote for a whole new library of string functions - ones that are rational!
[8:33]	Dr Scofield:	lol
[8:33]	Babbage Linden:	i'd need to look in to allowing others
[8:33]	Saijanai Kuhn:	Talk to Grady BOoch
[8:33]	Gale Barzane:	Ha ha ha ha - he he he!!! =D
[8:34]	Tree Kyomoon:	ECMA compliance mabey?
[8:34]	Zero Linden:	Now, ECMA script - there is a decent idea for a target language
[8:34]	Zha Ewry:	Well, Zero. if we also lose the 2X memory use for string touching.. that would help ;)
[8:34]	Tree Kyomoon:	instead of a fun made up language with silly functions and lots of in jokes?
[8:34]	Zero Linden:	there are in-jokes in LSL?
[8:35]	Tree Kyomoon:	I think so...but I'll have to get back to you with examples, I just remember some from the wiki as Ive been learning it
[8:35]	Tedd Maa:	yeah, I found at least one ADD function not needed in the bytecode
[8:35]	Dr Scofield wants XMPP support
[8:36]	Tedd Maa:	so, is it wrong to ask about timeframe for Mono?
[8:36]	Tree Kyomoon:	no offence of course, I enjoy working in LSL, just would be great to have an ECMA scripting language ... LSL could do what Flash actionscript did back in 2000
[8:36]	Saijanai Kuhn:	after hetgrid
[8:36]	Babbage Linden:	we're hoping to get mono running as a client of hetgrid
[8:36]	Babbage Linden:	this quarter
[8:36]	Babbage Linden:	but, that depends on progress on both mono and hetgrid
[8:36]	Zha Ewry:	Do you have any sense of the testing window? I'd imagine it's going to be huge
[8:36]	Tedd Maa:	thats nice
[8:37]	Saijanai Kuhn:	when did the quarter start, BTW?
[8:37]	Zha Ewry:	Scripts are so pervasive
[8:37]	Zero Linden:	Het Grid phase 1 should roll out next week or two -- then we'll be able to bring up a few "beta" regions on the main grid running mono
[8:38]	Tedd Maa:	Saijanai: He didn't say what YEAR ;) (programmers never do)
[8:38]	Zero Linden:	Saijani - July 1st - LL operates on calendar quarters
[8:38]	Gale Barzane:	grin
[8:38]	Babbage Linden:	we're going to be writing as many test scripts as we can to compare mono with LSL2
[8:38]	Babbage Linden:	but the goal of running on agni is to allow developers to test their own scripts
[8:38]	Babbage Linden:	and report inconsistencies
[8:38]	Babbage Linden:	and problems
[8:38]	Saijanai Kuhn:	Roughly what I expected from remarks you made recently, Zero
[8:38]	Tree Kyomoon likes the sound of that...."LSL2" :)
[8:39]	Saijanai Kuhn:	LSL = LSL2
[8:39]	Babbage Linden:	i could imagine mono being in testing as a het grid client for a number of quarters
[8:39]	Zha Ewry:	Sure.. The problem I fear most, Babbage.. is the question of having to see whether fixes to solve one set of problems breaks other ones
[8:39]	Zha Ewry:	I'
[8:39]	Zha Ewry:	I
[8:39]	Babbage Linden:	that is always a fear ;-)
[8:39]	Tree Kyomoon:	thats the nature of progress isnt it?
[8:39]	Zha Ewry:	would sort of expect to see the first 75% be pretty easy
[8:40]	Babbage Linden:	there will be the option of scripts running on LSL2 for a long time
[8:40]	Zha Ewry:	and the last 25% to be a lot of stuff like that. "What do we chose to break, we're going to break soemthine." kind of discussions
[8:40]	Saijanai Kuhn:	Seems to me that tracking problem areas in living scripts in various sims will need to be automated
[8:40]	Babbage Linden:	even after mono is mainstream
[8:40]	Gale Barzane:	Giggles @ zha but its true
[8:40]	Babbage Linden:	we will require people to test scripts and report problems
[8:41]	Babbage Linden:	as there's no way of knowing how a script is supposed to behave
[8:41]	Saijanai Kuhn:	a lot of doorways...
[8:41]	Zero Linden:	remember that we will be keeping the LSL VM for quite a while - and so existing scripts will execut with existing semantics well after mono is the norm.
[8:41]	Tree Kyomoon:	once LSL gets more sophisticated, I'll probably become more full time in here
[8:41]	Zero Linden:	so if we have to say ... well, under mono, X or Y or Z is different, we can
[8:41]	Zha Ewry:	Do you have a sense of how many unique scripts exist on SL?
[8:42]	Tedd Maa:	so if someone made a LSL to C¬§ converter it would be good..? ;)
[8:42]	Babbage Linden:	lots
[8:42]	Babbage Linden:	12000 unique scripts a week...
[8:42]	Dr Scofield:	new scripts?
[8:42]	Saijanai Kuhn:	unique as in their own compile, rather than just a copy
[8:42]	Zero Linden:	yes - there are 21.7M unique scripts
[8:42]	Zha Ewry:	Unique defines in what sense?
[8:43]	Zero Linden:	mind you- if you open a script, change nothing, but hit compile, that is another unique script
[8:43]	Tree Kyomoon:	so there are more lines of code in the scripts than in SL itself?
[8:43]	Zha Ewry:	Ah.
[8:43]	Babbage Linden:	yes, 3m lines of code a week
[8:43]	Tedd Maa:	considered hashing them for .Net to maximize shared memory? (hashing code to see if it already has been compiled)
[8:43]	Gale Barzane:	wow
[8:43]	Zero Linden:	but if you copy a script, that isn't a unique copy
[8:43]	Saijanai Kuhn preens again
[8:43]	Zha Ewry:	It would be nice to do some of the tricks people have done to take hashes of those scripts and then see how many are dupes.
[8:43]	Zero Linden:	Tree by two orders of magnitude
[8:43]	Saijanai Kuhn:	(twice in one day--astounding!)
[8:44]	Zero Linden:	Zha - well, it would interesting... but not at present important
[8:44]	Zero Linden:	and you'dhave to d white space compression on 'em
[8:44]	Tedd Maa:	wow, my HUD I pushed 1 hour ago responded!
[8:44]	Tree Kyomoon:	you know you are a success when the stuff flowing in your pipes is orders of magnatude more than the pipes themselves
[8:44]	Tree Kyomoon:	congrats lindens!
[8:44]	Zero Linden:	or you could look for dups in the bytecode. I suppose
[8:44]	Zha Ewry:	Well.. as you get to testing.. it will help you to know when you've got to rational coverage
[8:45]	Saijanai Kuhn:	right now, you have delays built into scripts. How will those delays get tranlsated into mono?
[8:45]	Zero Linden:	they are identical
[8:46]	Zero Linden:	they are done in the library calls
[8:46]	Tedd Maa:	delays? are they intentional?
[8:46]	Zero Linden:	which remain the same
[8:46]	Zha Ewry:	Yeah, the "1 second per e-mail" kind of stuff
[8:46]	Saijanai Kuhn:	they're listed on teh wikis
[8:46]	Tedd Maa:	ah, those..
[8:46]	Zha Ewry:	Some of which can be subverted
[8:46]	Saijanai Kuhn:	.2 for llsetprimparams
[8:46]	Zha Ewry:	In various interesting ways
[8:46]	Tree Kyomoon:	is ECMA in the plans or should I formally request it?
[8:46]	Saijanai Kuhn 's first object hsa 22 scripts to get around delays
[8:46]	Babbage Linden:	i think ECMA script runs on mono
[8:46]	Kri Ayakashi:	regarding delays... some function could work better with throttling (like llHTTPRequest) instead of delaying them (ie llSetPos or sending IMs via LSL)
[8:47]	Tree Kyomoon:	ECMA for LSL I mean
[8:47]	Babbage Linden:	a specification for LSL?
[8:47]	Zha Ewry:	Well, what is really wanted, is delays, per object, not per script..
[8:47]	Babbage Linden:	that would be nice...
[8:47]	Saijanai Kuhn:	way in the future to figure out how to do away with states, I'm betting
[8:47]	Zha Ewry:	The current bypassing scheme where you run mulitple scripts to avoid the delays.. is a clear hint that the throttle is on the wrong level of grain size
[8:48]	Tree Kyomoon would like to see LSL mimic Javascript exactly
[8:48]	Saijanai Kuhn:	states?
[8:48]	Saijanai Kuhn:	events?
[8:48]	Zero Linden:	Saijanai - states are actually one of the few interesting language features of LSL I think
[8:48]	Tedd Maa:	Tree: I would like to see it mimic .Net :)
[8:48]	Tree Kyomoon:	more javascript developers, less learning curve
[8:49]	Zero Linden:	though, they are really a lingustic convience, not a fundimental feature
[8:49]	Saijanai Kuhn:	was just wondering how to implmement LSL states and events in a "pure" port of JavaScript
[8:49]	Tedd Maa:	how are states handled in .Net? hook/unhooking events?
[8:49]	Tree Kyomoon:	and not owned by microsoft
[8:49]	Babbage Linden:	i've implemented states just via name mangling
[8:49]	Zero Linden:	kind of like a table of call backs and some useful methods for swapping between them (with calling state_entry and state_exit)
[8:49]	Zero Linden:	there will not likely be a "pure" port of any language
[8:49]	Zha Ewry:	Zero, while states are cooll it would be nice if you didn't have to dupe so much code to use them.
[8:49]	Zero Linden:	there can't be
[8:50]	Babbage Linden:	when you switch states, i use reflection to look for handlers prefixed with the state name
[8:50]	Babbage Linden:	then set them up as the current handlers
[8:50]	Zha Ewry:	It would be really nice if you coul dhave some event handlers.. thaty spanned states
[8:50]	Gale Barzane:	i see you up there scouse
[8:50]	Zero Linden:	for example, most languages say "a program starts at main()" or some such
[8:50]	Babbage Linden:	hi scouse
[8:50]	Scouse Linden:	hi
[8:50]	Dr Scofield:	C# events
[8:50]	Zero Linden:	others say "a script is executed from the top..."
[8:50]	Gale Barzane:	hi
[8:50]	Zero Linden:	these things don't make sense in our executing environment
[8:50]	Dr Scofield:	hi scouse
[8:50]	Babbage Linden:	everyone, scouse is helping with mono
[8:51]	Saijanai Kuhn:	LSL is more like old-school MacOS drivers
[8:51]	Zha Ewry:	Hello Scouse...
[8:51]	Scouse Linden:	Hello everyone
[8:51]	Tedd Maa:	hi there
[8:51]	Kri Ayakashi:	hi
[8:51]	Zha Ewry:	Wow default ave Linden.
[8:51]	Saijanai Kuhn:	yo
[8:51]	Saijanai Kuhn:	born almost yesterday
[8:52]	Tree Kyomoon:	if you use Javascript as your spec for LSL, you would have instant translation to the hundreds of thousands of flash actionscripters, javascripters, by far the largest group of scripters on the internet
[8:52]	Tedd Maa:	6 days ago
[8:52]	Babbage Linden:	tree, i'd rather allow assembly upload and the let people compile EMCA to .NET assemblies
[8:52]	Saijanai Kuhn:	Same arugment for Lua and client scripting
[8:52]	Babbage Linden:	which i think is possible
[8:53]	Dr Scofield thinks assembly upload is a good idea
[8:53]	Saijanai Kuhn used to learn a different asembler every year or two.
[8:53]	Zha Ewry:	Well, if you don't blow up on verification.. I'd wonder how many of the
[8:53]	Zha Ewry:	compilers will build verifiably safe code
[8:53]	Dr Scofield:	lol
[8:53]	Tree Kyomoon:	/as long as all the tools were accesible inside the client and didnt require some highly technical set up
[8:53]	Tree Kyomoon:	the more you can develop in world the better
[8:53]	Kri Ayakashi:	Babbage what's the progress on microthreading in Mono?
[8:53]	Zha Ewry:	With that path.. you're totally hung up, if your compiler happens to build one fragment routinely that can't be verifiried safely
[8:53]	Saijanai Kuhn client needs plug-in API for editors
[8:54]	Dr Scofield:	tree, you could use the language of your choice
[8:54]	Tedd Maa:	but this Mono code verifier, when is it ready?
[8:54]	Babbage Linden:	i should get a list of compilers which output verifiable code
[8:54]	Zha Ewry:	That would be insanely useful, Bababge
[8:54]	Tedd Maa:	I would guess it is a very good thing for Mono to help out on this project as it will open doors to all virtual worlds
[8:54]	Jarod Godel:	Is uploading .NET bytecode better than uploading source, because it saves on SL from having to compile?
[8:54]	Zha Ewry:	It saves SL from having to support dozens of com[ilers
[8:55]	Saijanai Kuhn:	jst faster implementation of native code, I think
[8:55]	Kri Ayakashi:	like CCP (makers of EVE) are helping outh Stackless and vice versa :)
[8:55]	Tree Kyomoon:	right but it sounds like you guys propose people having some kind of compiler and external scripting environment, which is sub optimal for most amateur scripters, and removes the sense of immersion
[8:55]	Jarod Godel:	Thanks, Zha
[8:55]	Babbage Linden:	exactly, zha
[8:55]	Saijanai Kuhn:	dont' have to wait for YAC
[8:55]	Babbage Linden:	tree, there will always be LSL
[8:55]	Saijanai Kuhn:	like I said, need a plug-in API for the client
[8:55]	Zha Ewry:	Well.. You can do most of that with client side plugins
[8:55]	Jarod Godel:	I want to run SL in Komodo. :)
[8:55]	Saijanai Kuhn:	either that, or a chat exporter API so you can chat while scripting in the external app
[8:56]	Jarod Godel:	or vice versa. ;)
[8:56]	Zha Ewry:	if you have a commpile/edit environemnt... which plugs into the client.. you're 90% of the way
[8:56]	Jarod Godel:	Saijanai, that should be doable with message liberation
[8:56]	Saijanai Kuhn:	or implement CLI interpreter in croquet/Smalltalk after I get the chat I/O working
[8:56]	Jarod Godel:	once they setup a Jabber/SL gatewway
[8:56]	Tree Kyomoon:	yes, but if LSL were just ECMA, then it would be more powerful would it not? WHy the need for all the kluges?
[8:56]	Tedd Maa:	compiling client side should be easy - just add reference to an interface and ask Mono to compile
[8:57]	Saijanai Kuhn:	yo uneed to keep a client-reference for chat
[8:57]	Tedd Maa:	stand-alone app for that wouldn't take long to fix up
[8:57]	Zha Ewry:	The immersion question is useful.. to keep in mind
[8:57]	Saijanai Kuhn:	Jabber handles SL IM and chat channels?
[8:57]	Jarod Godel:	No it's not.
[8:57]	Tedd Maa:	but Mono doesn't (afaik) have any good editor objects?
[8:57]	Babbage Linden:	mono has monodevelop
[8:57]	Tedd Maa:	so for most people using Visual Studio C¬§ Express would be a good choice
[8:57]	Babbage Linden:	which i haven't used
[8:57]	Tree Kyomoon:	yes, for some of us, scripting is like building, its part of the experience. Of course I can code in other languages, but I dont want to!
[8:57]	Dr Scofield:	emacs
[8:58]	Babbage Linden:	vs express would be my suggestion
[8:58]	Zha Ewry:	I was playing with scritpting in nother VW .. and it was a loop of 2d edit tool, upload, break, exit world edit...
[8:58]	Zha Ewry:	ik
[8:58]	Jarod Godel:	Even as far back as Snowcrash, there's been a decided realization between a 3d metaverssse for socializing and a 2d desktop for coding.
[8:58]	Saijanai Kuhn:	the proposed SL lite client with floating windows for chat would work
[8:58]	Babbage Linden:	and ms have expressed interest in building an sl project template for vs express
[8:58]	Saijanai Kuhn:	but immerision is chat + 3D rpesence, not necessarily in that order
[8:58]	Tree Kyomoon:	/tree doesnt like to leave SL to sculpt, script, or create any in world content...should be able to make it all in world!
[8:58]	Daedalus Young:	hi!
[8:59]	Saijanai Kuhn:	Croquet as private sandbox... ;-)
[8:59]	Zha Ewry:	I actaully think that the revert to 2d thought.. is people who haven't done immersion
[8:59]	Zha Ewry:	not based on any actualy people who have done both
[8:59]	Zha Ewry:	*actual
[9:00]	Dr Scofield thinks for true immersion we need to be able to extend the client easily, currently we only have grid side immersion
[9:00]	Jarod Godel:	Zha, I disagree. Even when I program in SL, "in 3D," I go to a 2D mindset.
[9:00]	Wyn Galbraith:	How much did I miss?
[9:00]	Dr Scofield:	wyn, everything
[9:00]	Jarod Godel:	I just move script and notes around my screen like i would a desktop
[9:00]	Tree Kyomoon:	you do jarod, but I dont
[9:00]	Wyn Galbraith:	Grasmere was down wasn't it?
[9:00]	Saijanai Kuhn:	Zero logging in for 40 minutes
[9:00]	Zha Ewry:	I don't either
[9:01]	Jarod Godel:	How do "program in 3D?"
[9:01]	Dr Scofield:	wyn, no, but grid is having a bad net day
[9:01]	Tree Kyomoon:	/thats why I love objects and arrays so much, I visualize everything in 3d
[9:01]	Zero Linden:	I'm pretty sure we all want the same thing: We want to be able to be in SL, script our objects (what is the point of the script w/o the objects) BUT have a productive tool set
[9:01]	Daedalus Young:	yes, we noticed :P
[9:01]	Zha Ewry:	I keep fragments on scripts in seperate objects and drag them around.
[9:01]	Saijanai Kuhn:	building is a 3D thing. Scripting may be 2D but it is ONLY building-oriented
[9:01]	Kri Ayakashi:	Jarod the IBM MPK20 would be a good example or 3d objects in Croquet
[9:01]	Zero Linden:	I don't think there is anything non-immersive about a good tool set
[9:01]	Wyn Galbraith:	We couldn't get here, it was gone, just ahole in the ground.
[9:01]	Zha Ewry:	Chuckle. We've been her for the past hour.
[9:01]	Jarod Godel:	Tree, I'm talking strictly about tool usage, not visualizing algorithms
[9:02]	Saijanai Kuhn:	SL immersive. Professional s immerse in waht they are doing. SL citizens dabble and immerse in SL
[9:02]	Kri Ayakashi:	you can have an application on a 3D prim and you can interface it with mouse and keyboard like you would with it when it's in 2D
[9:02]	Tree Kyomoon:	zero its only non immersive if you have to leave SL and run some huge spaghetti mess like Visual Studio in order to make some thing intended for SL
[9:02]	Saijanai Kuhn contemplates that there's immersion and being mired...
[9:02]	Tedd Maa:	question Babbage - you said there will be running LSL VM scripts for a long time still. but if a user does a small change and resubmits script it will be .Net, right?
[9:02]	Zha Ewry:	Even on tool usage, what I want to do is have the code fragments sitting around in objects in my workspace in SL.. and play with them so several people can see them at once
[9:03]	Dr Scofield would like the ability to map emacs window into SL
[9:03]	Jarod Godel:	Zha, like Popfly?
[9:03]	Zero Linden:	Friends - I realize that we started late - and that many couldn't get here
[9:03]	Zero Linden:	BUT,
[9:03]	Saijanai Kuhn is still workign on that chat I/O for croquet
[9:03]	Zha Ewry:	One hallmark of immersion in SL for me.. is that I can use SL for the collaboration
[9:03]	Babbage Linden:	while we test mono/LSL2 compatibility you will be able to target both VMs
[9:03]	Zero Linden:	we've now been here for an hour
[9:03]	Dr Scofield:	you are kicking us out
[9:03]	Dr Scofield:	:-)
[9:03]	Zha Ewry:	No, he's leaving
[9:03]	Zha Ewry:	He never kids us out
[9:03]	Zero Linden:	and I'd like to wrap up ... let Babbage and Scouse eat dinner, etc....
[9:03]	Zha Ewry:	We can hang around and talk
[9:03]	Zha Ewry:	But He pops...
[9:03]	Saijanai Kuhn:	thanks for taking the full hour Zero
[9:04]	Dr Scofield:	thx!
[9:04]	Saijanai Kuhn:	and then some
[9:04]	Zha Ewry:	This was great, Zero, as always
[9:04]	Tree Kyomoon:	thanks zero
[9:04]	Dr Scofield was just kidding
[9:04]	Babbage Linden:	long term we'd like to have new scripts only target mono
[9:04]	Zero Linden:	HOWEVER
[9:04]	Babbage Linden:	but we'll see how things work out
[9:04]	Tree Kyomoon:	hope I was helpful...sorryfor being a luddite
[9:04]	Zero Linden:	due to the grid issues
[9:04]	Tedd Maa:	Zero: want logs from start?
[9:04]	Saijanai Kuhn glances at his group name
[9:04]	Zero Linden:	I'd like to invite Babbage and Scouse back and do this again -- in about two weeks
[9:04]	Zha Ewry:	Oooh. Cool.
[9:04]	Adam Xinpeng:	Ack, hope I havnt missed this all
[9:04]	Tree Kyomoon:	yay!
[9:04]	Daedalus Young:	that would be great
[9:04]	Zero Linden:	Tedd - yes please, e-mail to zero.linden@secondlife.com
[9:04]	Zha Ewry:	Very good, Zero..
[9:05]	Dr Scofield:	thx!
[9:05]	Zha Ewry:	I also have a full set, if Tedd doesn't.
[9:05]	Zero Linden:	Babbage and Scouse - thanks for coming
[9:05]	Babbage Linden:	no problem
[9:05]	Zero Linden:	And thanks everyone else too
[9:05]	Saijanai Kuhn thanks everyone, sepcially Lindens in attendance
[9:05]	Babbage Linden:	thanks for coming everyone
[9:05]	Jarod Godel:	Lindens, one quick thing if I may
[9:05]	Zha Ewry:	Super discussion Babbage
[9:05]	Babbage Linden:	and for a good discussion
[9:05]	Tedd Maa:	thanks :)
[9:05]	Zha Ewry:	And some real food for thought
[9:05]	Dr Scofield:	thx for a good discussion!
[9:05]	Jarod Godel:	do you know who i should contact to get in the "developer" group?
[9:06]	Babbage Linden:	see you all in a couple of weeks, i hope
[9:06]	Daredevil Loon:	hello
[9:06]	Daedalus Young:	thanks!
[9:06]	Wyn Galbraith hopes this log will be posted soon?
[9:07]	Tree Kyomoon:	in case anyone is interested, there is some land for sale in Da Boom. I already bought a chunk that im not selling, but its some historic value as SL's first sim
[9:07]	Zero Linden:	will try
[9:07]	Adam Xinpeng:	Heh
[9:07]	Adam Xinpeng:	Da Boom is misquoted there
[9:07]	Adam Xinpeng:	it was the one next to it, freema or whatever.
[9:07]	Saijanai Kuhn:	oops
[9:07]	Jarod Godel:	Zha, I'm not opposed to what you suggest, but I don't want "user immersion" to be the driving design behind "developer interfaces."