Talk:Mono - Revision history

Strife Onizuka: /* Why is this page referring to LSL2, and not LSO ? */ physics

2012-02-19T07:39:28Z

Why is this page referring to LSL2, and not LSO ?: physics

← Older revision		Revision as of 00:39, 19 February 2012
Line 54:		Line 54:
	I find the term LSL2 somewhat misleading, as it implies to me that there's a difference in the actual scripting language (LSL) depending on whether the script is going to compiled in Mono or LSO bytecode.[[User:PixelProphet Lane\|PixelProphet Lane]] 16:51, 11 February 2012 (PST)		I find the term LSL2 somewhat misleading, as it implies to me that there's a difference in the actual scripting language (LSL) depending on whether the script is going to compiled in Mono or LSO bytecode.[[User:PixelProphet Lane\|PixelProphet Lane]] 16:51, 11 February 2012 (PST)
	: It is the difference between LL's internal names and what turns up on the public side. This appears in other places too, for example public documentation uses "physical and nonphysical" objects while Lindens talk about "dynamic and static". There has been a profound communication disconnect between LL and its customers for years and years, the documentation warts are small artifacts of a much bigger problem. --[[User:Cerise Sorbet\|Cerise Sorbet]] 20:57, 11 February 2012 (PST)		: It is the difference between LL's internal names and what turns up on the public side. This appears in other places too, for example public documentation uses "physical and nonphysical" objects while Lindens talk about "dynamic and static". There has been a profound communication disconnect between LL and its customers for years and years, the documentation warts are small artifacts of a much bigger problem. --[[User:Cerise Sorbet\|Cerise Sorbet]] 20:57, 11 February 2012 (PST)

			::That problem stems from [[STATUS_PHYSICS]] etc. LL has been terrible at naming things in LSL. Poor interface design. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:39, 18 February 2012 (PST)

	:I popularized calling it LSO, at the time we only knew of LSL2 as the language, in hind sight that may not have been the case. When Mono was being rolled out I had a problem, when writing about the old VM, what do I call it. There were two issues here: In the bad old days things didn't really have well defined edges, there was one changelog for both the server and client. Likewise, LSL as a language, compiler and VM were all a package. There was an [http://secondlife.wikia.com/wiki/LSL1 LSL1], and the LSO VM still supports it but there isn't a compiler for it. So where did LSO come from? LSO was the (internal) asset type for a compiled script. So the question is: Is it the LSL2 VM (which is down compatible with LSL1 LSO) and LSL2 language (not down compatible with LSL1 language) using the LSO type for it's compiled assets; or is it the LSL2 language (not down compatible with LSL1) and the LSO VM (which runs LSL1 & LSL2 LSO compiled scripts). The second solution is a lot less complicated and is what I assumed was correct. There is likely no correct answer to this as LSL2 may never have been given a tight definition and scope. I might have been wrong but until today I had never considered it. I will say it is easier to refer to it as LSO since the first fundamental difference between the two VMs is the type of bytecode they run. This is the sort of thing you could ask at the [[Beta Server Office Hours]].		:I popularized calling it LSO, at the time we only knew of LSL2 as the language, in hind sight that may not have been the case. When Mono was being rolled out I had a problem, when writing about the old VM, what do I call it. There were two issues here: In the bad old days things didn't really have well defined edges, there was one changelog for both the server and client. Likewise, LSL as a language, compiler and VM were all a package. There was an [http://secondlife.wikia.com/wiki/LSL1 LSL1], and the LSO VM still supports it but there isn't a compiler for it. So where did LSO come from? LSO was the (internal) asset type for a compiled script. So the question is: Is it the LSL2 VM (which is down compatible with LSL1 LSO) and LSL2 language (not down compatible with LSL1 language) using the LSO type for it's compiled assets; or is it the LSL2 language (not down compatible with LSL1) and the LSO VM (which runs LSL1 & LSL2 LSO compiled scripts). The second solution is a lot less complicated and is what I assumed was correct. There is likely no correct answer to this as LSL2 may never have been given a tight definition and scope. I might have been wrong but until today I had never considered it. I will say it is easier to refer to it as LSO since the first fundamental difference between the two VMs is the type of bytecode they run. This is the sort of thing you could ask at the [[Beta Server Office Hours]].
	: -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:35, 18 February 2012 (PST)		: -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:35, 18 February 2012 (PST)

Strife Onizuka: /* Why is this page referring to LSL2, and not LSO ? */

2012-02-19T07:35:37Z

Why is this page referring to LSL2, and not LSO ?

← Older revision		Revision as of 00:35, 19 February 2012
Line 54:		Line 54:
	I find the term LSL2 somewhat misleading, as it implies to me that there's a difference in the actual scripting language (LSL) depending on whether the script is going to compiled in Mono or LSO bytecode.[[User:PixelProphet Lane\|PixelProphet Lane]] 16:51, 11 February 2012 (PST)		I find the term LSL2 somewhat misleading, as it implies to me that there's a difference in the actual scripting language (LSL) depending on whether the script is going to compiled in Mono or LSO bytecode.[[User:PixelProphet Lane\|PixelProphet Lane]] 16:51, 11 February 2012 (PST)
	: It is the difference between LL's internal names and what turns up on the public side. This appears in other places too, for example public documentation uses "physical and nonphysical" objects while Lindens talk about "dynamic and static". There has been a profound communication disconnect between LL and its customers for years and years, the documentation warts are small artifacts of a much bigger problem. --[[User:Cerise Sorbet\|Cerise Sorbet]] 20:57, 11 February 2012 (PST)		: It is the difference between LL's internal names and what turns up on the public side. This appears in other places too, for example public documentation uses "physical and nonphysical" objects while Lindens talk about "dynamic and static". There has been a profound communication disconnect between LL and its customers for years and years, the documentation warts are small artifacts of a much bigger problem. --[[User:Cerise Sorbet\|Cerise Sorbet]] 20:57, 11 February 2012 (PST)

			:I popularized calling it LSO, at the time we only knew of LSL2 as the language, in hind sight that may not have been the case. When Mono was being rolled out I had a problem, when writing about the old VM, what do I call it. There were two issues here: In the bad old days things didn't really have well defined edges, there was one changelog for both the server and client. Likewise, LSL as a language, compiler and VM were all a package. There was an [http://secondlife.wikia.com/wiki/LSL1 LSL1], and the LSO VM still supports it but there isn't a compiler for it. So where did LSO come from? LSO was the (internal) asset type for a compiled script. So the question is: Is it the LSL2 VM (which is down compatible with LSL1 LSO) and LSL2 language (not down compatible with LSL1 language) using the LSO type for it's compiled assets; or is it the LSL2 language (not down compatible with LSL1) and the LSO VM (which runs LSL1 & LSL2 LSO compiled scripts). The second solution is a lot less complicated and is what I assumed was correct. There is likely no correct answer to this as LSL2 may never have been given a tight definition and scope. I might have been wrong but until today I had never considered it. I will say it is easier to refer to it as LSO since the first fundamental difference between the two VMs is the type of bytecode they run. This is the sort of thing you could ask at the [[Beta Server Office Hours]].
			: -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:35, 18 February 2012 (PST)

Cerise Sorbet: /* Why is this page referring to LSL2, and not LSO ? */

2012-02-12T04:57:32Z

Why is this page referring to LSL2, and not LSO ?

← Older revision		Revision as of 21:57, 11 February 2012
Line 53:		Line 53:
	Shouldn't LSL2 be replaced with LSO ?		Shouldn't LSL2 be replaced with LSO ?
	I find the term LSL2 somewhat misleading, as it implies to me that there's a difference in the actual scripting language (LSL) depending on whether the script is going to compiled in Mono or LSO bytecode.[[User:PixelProphet Lane\|PixelProphet Lane]] 16:51, 11 February 2012 (PST)		I find the term LSL2 somewhat misleading, as it implies to me that there's a difference in the actual scripting language (LSL) depending on whether the script is going to compiled in Mono or LSO bytecode.[[User:PixelProphet Lane\|PixelProphet Lane]] 16:51, 11 February 2012 (PST)
			: It is the difference between LL's internal names and what turns up on the public side. This appears in other places too, for example public documentation uses "physical and nonphysical" objects while Lindens talk about "dynamic and static". There has been a profound communication disconnect between LL and its customers for years and years, the documentation warts are small artifacts of a much bigger problem. --[[User:Cerise Sorbet\|Cerise Sorbet]] 20:57, 11 February 2012 (PST)

PixelProphet Lane: /* Why is this page referring to LSL2, and not LSO ? */ new section

2012-02-12T00:51:17Z

Why is this page referring to LSL2, and not LSO ?: new section

← Older revision		Revision as of 17:51, 11 February 2012
Line 46:		Line 46:

	Oddly enough different .net functions that do basically the same things run at different speeds. It may be of interest to read this article: [http://www.codeproject.com/KB/cs/StringBuilder_vs_String.aspx?fid=326464&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr=26 StringBuilder vs. String / Fast String Operations with .NET 2.0]. The information may not be totally applicable with Mono but it should get you thinking. -- [[User:Strife Onizuka\|Strife Onizuka]] 17:31, 4 April 2008 (PDT)		Oddly enough different .net functions that do basically the same things run at different speeds. It may be of interest to read this article: [http://www.codeproject.com/KB/cs/StringBuilder_vs_String.aspx?fid=326464&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr=26 StringBuilder vs. String / Fast String Operations with .NET 2.0]. The information may not be totally applicable with Mono but it should get you thinking. -- [[User:Strife Onizuka\|Strife Onizuka]] 17:31, 4 April 2008 (PDT)

			== Why is this page referring to LSL2, and not LSO ? ==

			To my knowledge, the old scripting engine is LSO VM, which requires LSO bytecode.
			In various locations on this page, I see LSL2 being mentioned, for example ''Performance benchmark tests show that Mono is up to 220 times faster than LSL2.''.
			Shouldn't LSL2 be replaced with LSO ?
			I find the term LSL2 somewhat misleading, as it implies to me that there's a difference in the actual scripting language (LSL) depending on whether the script is going to compiled in Mono or LSO bytecode.[[User:PixelProphet Lane\|PixelProphet Lane]] 16:51, 11 February 2012 (PST)

Strife Onizuka: /* Optimization */

2008-04-05T00:31:42Z

Optimization

← Older revision		Revision as of 17:31, 4 April 2008
Line 45:		Line 45:
	== Optimization ==		== Optimization ==

	Oddly enough different .net functions that do basically the same things run at different speeds. It may be of interest to read this article: [http://www.codeproject.com/KB/cs/StringBuilder_vs_String.aspx?fid=326464&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr=26 StringBuilder vs. String / Fast String Operations with .NET 2.0]		Oddly enough different .net functions that do basically the same things run at different speeds. It may be of interest to read this article: [http://www.codeproject.com/KB/cs/StringBuilder_vs_String.aspx?fid=326464&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr=26 StringBuilder vs. String / Fast String Operations with .NET 2.0]. The information may not be totally applicable with Mono but it should get you thinking. -- [[User:Strife Onizuka\|Strife Onizuka]] 17:31, 4 April 2008 (PDT)

Strife Onizuka: New section: Optimization

2008-04-05T00:31:02Z

New section: Optimization

← Older revision		Revision as of 17:31, 4 April 2008
Line 42:		Line 42:

	Strife has it correct. The compilation is done by a process running on each mono-enabled sim host. [[User:Periapse Linden\|Periapse Linden]] 12:20, 30 January 2008 (PST)		Strife has it correct. The compilation is done by a process running on each mono-enabled sim host. [[User:Periapse Linden\|Periapse Linden]] 12:20, 30 January 2008 (PST)

			== Optimization ==

			Oddly enough different .net functions that do basically the same things run at different speeds. It may be of interest to read this article: [http://www.codeproject.com/KB/cs/StringBuilder_vs_String.aspx?fid=326464&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr=26 StringBuilder vs. String / Fast String Operations with .NET 2.0]

Strife Onizuka: /* Mono Benchmarks */

2008-02-05T02:09:14Z

Mono Benchmarks

← Older revision		Revision as of 19:09, 4 February 2008
Line 2:		Line 2:

	I notice that the benchmarks listed seem to mostly be numeric. Has anyone done any benchmarks on string and list processing? [[User:Lee Ponzu\|Lee Ponzu]] 08:36, 4 February 2008 (PST)		I notice that the benchmarks listed seem to mostly be numeric. Has anyone done any benchmarks on string and list processing? [[User:Lee Ponzu\|Lee Ponzu]] 08:36, 4 February 2008 (PST)

			:I was testing some encoding and decoding functions I wrote and ran both versions sided by side. Very string intensive. The Mono version finished the full circuit before the LSO had code finished the encoding.

	==Other languages==		==Other languages==

Lee Ponzu: Benchmark question

2008-02-04T16:36:10Z

Benchmark question

← Older revision		Revision as of 09:36, 4 February 2008
Line 1:		Line 1:
			==Mono Benchmarks==

			I notice that the benchmarks listed seem to mostly be numeric. Has anyone done any benchmarks on string and list processing? [[User:Lee Ponzu\|Lee Ponzu]] 08:36, 4 February 2008 (PST)

	==Other languages==		==Other languages==
	Here's a question about mono that the article doesn't address: Will scripters be limited to		Here's a question about mono that the article doesn't address: Will scripters be limited to

Periapse Linden: /* Compile Data Flow */

2008-01-30T20:20:53Z

Compile Data Flow

← Older revision		Revision as of 13:20, 30 January 2008
Line 34:		Line 34:
	#The bytecode is saved.		#The bytecode is saved.
	[[User:Strife Onizuka\|Strife Onizuka]] 16:01, 26 January 2008 (PST)		[[User:Strife Onizuka\|Strife Onizuka]] 16:01, 26 January 2008 (PST)

			Strife has it correct. The compilation is done by a process running on each mono-enabled sim host. [[User:Periapse Linden\|Periapse Linden]] 12:20, 30 January 2008 (PST)

Feynt Mistral: /* Other languages */

2008-01-30T17:32:17Z

Other languages

← Older revision		Revision as of 10:32, 30 January 2008
Line 16:		Line 16:

	:::::::Good point, I hadn't taken that into consideration. But if the script is a slave script without globals and not currently in an event that it won't have a stack or variables allocated. It should result in very little that needs serializing. I'm curious which system has a faster serialization of the event queue. -- [[User:Strife Onizuka\|Strife Onizuka]] 16:21, 28 January 2008 (PST)		:::::::Good point, I hadn't taken that into consideration. But if the script is a slave script without globals and not currently in an event that it won't have a stack or variables allocated. It should result in very little that needs serializing. I'm curious which system has a faster serialization of the event queue. -- [[User:Strife Onizuka\|Strife Onizuka]] 16:21, 28 January 2008 (PST)

			::::::::I'm just looking forward to using Python. I wonder if LL will give any sort of time frame (like late Q1, a few weeks after Mono releases, we'll be adding it during beta...) for adding other languages. I'd appreciate a little more script overhead so I could go nuts making class objects (like I normally do to make my life easier), but I suppose that will be subject to thorough testing as to whether any scripts currently in existence can push that 64kb cap. I'm also hoping sockets are retained, I'd like to be able to open connections to outside servers for whatever purposes I'd need. -- [[User:Feynt Mistral\|Feynt Mistral]] 09:32, 30 January 2008 (PST)

	==Compile Data Flow==		==Compile Data Flow==

← Older revision		Revision as of 00:39, 19 February 2012
Line 54:		Line 54:
	I find the term LSL2 somewhat misleading, as it implies to me that there's a difference in the actual scripting language (LSL) depending on whether the script is going to compiled in Mono or LSO bytecode.[[User:PixelProphet Lane\|PixelProphet Lane]] 16:51, 11 February 2012 (PST)		I find the term LSL2 somewhat misleading, as it implies to me that there's a difference in the actual scripting language (LSL) depending on whether the script is going to compiled in Mono or LSO bytecode.[[User:PixelProphet Lane\|PixelProphet Lane]] 16:51, 11 February 2012 (PST)
	: It is the difference between LL's internal names and what turns up on the public side. This appears in other places too, for example public documentation uses "physical and nonphysical" objects while Lindens talk about "dynamic and static". There has been a profound communication disconnect between LL and its customers for years and years, the documentation warts are small artifacts of a much bigger problem. --[[User:Cerise Sorbet\|Cerise Sorbet]] 20:57, 11 February 2012 (PST)		: It is the difference between LL's internal names and what turns up on the public side. This appears in other places too, for example public documentation uses "physical and nonphysical" objects while Lindens talk about "dynamic and static". There has been a profound communication disconnect between LL and its customers for years and years, the documentation warts are small artifacts of a much bigger problem. --[[User:Cerise Sorbet\|Cerise Sorbet]] 20:57, 11 February 2012 (PST)

			::That problem stems from [[STATUS_PHYSICS]] etc. LL has been terrible at naming things in LSL. Poor interface design. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:39, 18 February 2012 (PST)

	:I popularized calling it LSO, at the time we only knew of LSL2 as the language, in hind sight that may not have been the case. When Mono was being rolled out I had a problem, when writing about the old VM, what do I call it. There were two issues here: In the bad old days things didn't really have well defined edges, there was one changelog for both the server and client. Likewise, LSL as a language, compiler and VM were all a package. There was an [http://secondlife.wikia.com/wiki/LSL1 LSL1], and the LSO VM still supports it but there isn't a compiler for it. So where did LSO come from? LSO was the (internal) asset type for a compiled script. So the question is: Is it the LSL2 VM (which is down compatible with LSL1 LSO) and LSL2 language (not down compatible with LSL1 language) using the LSO type for it's compiled assets; or is it the LSL2 language (not down compatible with LSL1) and the LSO VM (which runs LSL1 & LSL2 LSO compiled scripts). The second solution is a lot less complicated and is what I assumed was correct. There is likely no correct answer to this as LSL2 may never have been given a tight definition and scope. I might have been wrong but until today I had never considered it. I will say it is easier to refer to it as LSO since the first fundamental difference between the two VMs is the type of bytecode they run. This is the sort of thing you could ask at the [[Beta Server Office Hours]].		:I popularized calling it LSO, at the time we only knew of LSL2 as the language, in hind sight that may not have been the case. When Mono was being rolled out I had a problem, when writing about the old VM, what do I call it. There were two issues here: In the bad old days things didn't really have well defined edges, there was one changelog for both the server and client. Likewise, LSL as a language, compiler and VM were all a package. There was an [http://secondlife.wikia.com/wiki/LSL1 LSL1], and the LSO VM still supports it but there isn't a compiler for it. So where did LSO come from? LSO was the (internal) asset type for a compiled script. So the question is: Is it the LSL2 VM (which is down compatible with LSL1 LSO) and LSL2 language (not down compatible with LSL1 language) using the LSO type for it's compiled assets; or is it the LSL2 language (not down compatible with LSL1) and the LSO VM (which runs LSL1 & LSL2 LSO compiled scripts). The second solution is a lot less complicated and is what I assumed was correct. There is likely no correct answer to this as LSL2 may never have been given a tight definition and scope. I might have been wrong but until today I had never considered it. I will say it is easier to refer to it as LSO since the first fundamental difference between the two VMs is the type of bytecode they run. This is the sort of thing you could ask at the [[Beta Server Office Hours]].
	: -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:35, 18 February 2012 (PST)		: -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:35, 18 February 2012 (PST)