use of C# in scripts

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

use of C# in scripts

Serendipity Seraph-2
I have run into some grids that are worried by a reported lack of
limitation on what C# classes and methods can be called.   Does anyone have
more detail on this?  It doesn't seem to me that putting in a script
scanner that would limit what calls to C# can and cannot go through would
be all that difficult.    So is the problem at the least over-inflated?  Is
the concern out of date or misplaced?
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: use of C# in scripts

Jeff Kelley
At 1:13 PM -0700 2/20/19, Serendipity Seraph wrote:

>I have run into some grids that are worried by a reported lack of
>limitation on what C# classes and methods can be called.   Does anyone have
>more detail on this?  It doesn't seem to me that putting in a script
>scanner that would limit what calls to C# can and cannot go through would
>be all that difficult.    So is the problem at the least over-inflated?  Is
>the concern out of date or misplaced?


I did some C# scripting years ago (computing, displaying black body
spectra in real time). Speed boost over LSL was x10.

Speed gain is much smaller today. Although i can no longer execute
the C# version, the LSL version which ran in 1.8s in 2011 is now
around a half second.

I also did some UDP communication, now replaced with HTTP which can
be awesomely fast.

The pain of LSL is still lack of data structures and modularity.

And it is a huge pain.


-- Jeff



_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: use of C# in scripts

Asaff Belfer
In reply to this post by Serendipity Seraph-2
Scripting by C# is somewhat limited as you cannot add references to .NET
libraries. The references that are supplied are pretty limited. As I recall
there was only a reference to System library and one more.

I actually wrote a POC that uses network sockets using C scripts. For that
I had to modify the source code of the simulator and add references to
libraries like System.Net.

So, we can say that the actions that you can do using C# scripting seem to
be pretty harmless as you don't have access to the network and file system
libraries. Even though, I'd take caution in allowing untrusted people to
write C# scripts.


Asaff


On Wed, Feb 20, 2019 at 10:13 PM Serendipity Seraph <[hidden email]>
wrote:

> I have run into some grids that are worried by a reported lack of
> limitation on what C# classes and methods can be called.   Does anyone have
> more detail on this?  It doesn't seem to me that putting in a script
> scanner that would limit what calls to C# can and cannot go through would
> be all that difficult.    So is the problem at the least over-inflated?  Is
> the concern out of date or misplaced?
> _______________________________________________
> Opensim-users mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: use of C# in scripts

AJLDuarte
In reply to this post by Serendipity Seraph-2
Hi,

     The use of C# ( or other .net language) in scripts is no longer a
supported feature.

     It is still possible using Xengine, but should only be used on
closed  secure environments.

     Yengine will not support it.

     regards,

Ubit



On 20-Feb-19 20:13, Serendipity Seraph wrote:

> I have run into some grids that are worried by a reported lack of
> limitation on what C# classes and methods can be called.   Does anyone have
> more detail on this?  It doesn't seem to me that putting in a script
> scanner that would limit what calls to C# can and cannot go through would
> be all that difficult.    So is the problem at the least over-inflated?  Is
> the concern out of date or misplaced?
> _______________________________________________
> Opensim-users mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: use of C# in scripts

Frisby, Adam
In reply to this post by Serendipity Seraph-2
void main() {
        main(); // Hi! :D
}

-----Original Message-----
From: [hidden email] <[hidden email]> On Behalf Of Serendipity Seraph
Sent: Thursday, 21 February 2019 7:13 AM
To: opensim-users <[hidden email]>
Subject: [Opensim-users] use of C# in scripts

I have run into some grids that are worried by a reported lack of
limitation on what C# classes and methods can be called.   Does anyone have
more detail on this?  It doesn't seem to me that putting in a script scanner that would limit what calls to C# can and cannot go through would
be all that difficult.    So is the problem at the least over-inflated?  Is
the concern out of date or misplaced?
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: use of C# in scripts

Serendipity Seraph-2
In reply to this post by AJLDuarte
Why not?  As a programmer I really despise LSL.  No real way to create
hardly any data structures.  It takes me back to antiquated Fortran
versions I started my career with so many decades ago.  No, worse than
that.

On Wed, Feb 20, 2019 at 2:20 PM Leal Duarte <[hidden email]> wrote:

> Hi,
>
>      The use of C# ( or other .net language) in scripts is no longer a
> supported feature.
>
>      It is still possible using Xengine, but should only be used on
> closed  secure environments.
>
>      Yengine will not support it.
>
>      regards,
>
> Ubit
>
>
>
> On 20-Feb-19 20:13, Serendipity Seraph wrote:
> > I have run into some grids that are worried by a reported lack of
> > limitation on what C# classes and methods can be called.   Does anyone
> have
> > more detail on this?  It doesn't seem to me that putting in a script
> > scanner that would limit what calls to C# can and cannot go through would
> > be all that difficult.    So is the problem at the least over-inflated?
> Is
> > the concern out of date or misplaced?
> > _______________________________________________
> > Opensim-users mailing list
> > [hidden email]
> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
> >
> _______________________________________________
> Opensim-users mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: use of C# in scripts

Asaff Belfer
I think that if C# is what you want to use then the script model is
probably not the right format for that.

It's pretty silly to write C# without the ability to use its advantages and
then have it stored as a C# code and be compiled again and again.

It could be much better if you could just use Visual Studio and deploy your
solution into the grid as a compiled product.

Asaff


On Sat, Feb 23, 2019 at 7:20 PM Serendipity Seraph <[hidden email]>
wrote:

> Why not?  As a programmer I really despise LSL.  No real way to create
> hardly any data structures.  It takes me back to antiquated Fortran
> versions I started my career with so many decades ago.  No, worse than
> that.
>
> On Wed, Feb 20, 2019 at 2:20 PM Leal Duarte <[hidden email]> wrote:
>
> > Hi,
> >
> >      The use of C# ( or other .net language) in scripts is no longer a
> > supported feature.
> >
> >      It is still possible using Xengine, but should only be used on
> > closed  secure environments.
> >
> >      Yengine will not support it.
> >
> >      regards,
> >
> > Ubit
> >
> >
> >
> > On 20-Feb-19 20:13, Serendipity Seraph wrote:
> > > I have run into some grids that are worried by a reported lack of
> > > limitation on what C# classes and methods can be called.   Does anyone
> > have
> > > more detail on this?  It doesn't seem to me that putting in a script
> > > scanner that would limit what calls to C# can and cannot go through
> would
> > > be all that difficult.    So is the problem at the least over-inflated?
> > Is
> > > the concern out of date or misplaced?
> > > _______________________________________________
> > > Opensim-users mailing list
> > > [hidden email]
> > > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
> > >
> > _______________________________________________
> > Opensim-users mailing list
> > [hidden email]
> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
> >
> _______________________________________________
> Opensim-users mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: use of C# in scripts

Dr Ramesh Ramloll
I think the assumption that C# should work only in closed secure
environments kind of narrows down the application space by quite a bit,
like 90% or more.
R

On Sat, Feb 23, 2019 at 3:01 PM Asaff Belfer <[hidden email]> wrote:

> I think that if C# is what you want to use then the script model is
> probably not the right format for that.
>
> It's pretty silly to write C# without the ability to use its advantages and
> then have it stored as a C# code and be compiled again and again.
>
> It could be much better if you could just use Visual Studio and deploy your
> solution into the grid as a compiled product.
>
> Asaff
>
>
> On Sat, Feb 23, 2019 at 7:20 PM Serendipity Seraph <[hidden email]
> >
> wrote:
>
> > Why not?  As a programmer I really despise LSL.  No real way to create
> > hardly any data structures.  It takes me back to antiquated Fortran
> > versions I started my career with so many decades ago.  No, worse than
> > that.
> >
> > On Wed, Feb 20, 2019 at 2:20 PM Leal Duarte <[hidden email]> wrote:
> >
> > > Hi,
> > >
> > >      The use of C# ( or other .net language) in scripts is no longer a
> > > supported feature.
> > >
> > >      It is still possible using Xengine, but should only be used on
> > > closed  secure environments.
> > >
> > >      Yengine will not support it.
> > >
> > >      regards,
> > >
> > > Ubit
> > >
> > >
> > >
> > > On 20-Feb-19 20:13, Serendipity Seraph wrote:
> > > > I have run into some grids that are worried by a reported lack of
> > > > limitation on what C# classes and methods can be called.   Does
> anyone
> > > have
> > > > more detail on this?  It doesn't seem to me that putting in a script
> > > > scanner that would limit what calls to C# can and cannot go through
> > would
> > > > be all that difficult.    So is the problem at the least
> over-inflated?
> > > Is
> > > > the concern out of date or misplaced?
> > > > _______________________________________________
> > > > Opensim-users mailing list
> > > > [hidden email]
> > > > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
> > > >
> > > _______________________________________________
> > > Opensim-users mailing list
> > > [hidden email]
> > > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
> > >
> > _______________________________________________
> > Opensim-users mailing list
> > [hidden email]
> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
> >
> _______________________________________________
> Opensim-users mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>


--
'Consider how the lilies grow. They do not labor or spin.'
*Rameshsharma Ramloll* PhD, CEO CTO DeepSemaphore LLC, Landisville, PA;
Affiliate *Research Associate Professor*, Idaho State University,
Pocatello, ID 83209 Tel: 208-240-0040
LinkedIn <http://www.linkedin.com/in/rameshramloll>
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: use of C# in scripts

Ethan Gardener
On Sat, Feb 23, 2019, at 8:11 PM, Dr Ramesh Ramloll wrote:
> I think the assumption that C# should work only in closed secure
> environments kind of narrows down the application space by quite a bit,
> like 90% or more.

Yeah.  It narrows it down to about the same space as custom modules, so why not write them instead?

This is one area where I wish OpenSim had branched out a bit; adding other languages, but I guess there was no-one to work on it.  I wasn't up to the task myself, as much as I wished I was.  Making a safe interpreter is non-trivial anyway.  Lately, I've been looking at one of the problems, avoiding memory leaks (which could lead to a denial of service attack or possibly an overflow exploit).  This alone is not at all easy to solve efficiently.  It would be better if modern computers descended from the Lisp Machines of the 1980s, they had hardware support for automatic garbage collection, but instead we have virtual memory schemes which make it hard for garbage collectors to work efficiently.  (I don't think anyone really wants to pay for the extra bits this needs.  The cost of memory was a huge limiting factor through the '80s and much of the '90s, and remains a little bit of a problem today.)

I can solve my problems with a relatively inefficient design, but that would be ridiculous in an environment where a single simulator may have to run thousands of scripts.  I could hypothetically write a full-blown garbage collector, but it's not worth it because such garbage collectors are notoriously prone to bugs, and *still* have efficiency problems.  Garbage collectors are one of those things which exponentially approach infinite complexity as they approach correctness and efficiency.  

Is a simple, efficient design possible?  Yes... if you limit the possible data structures.  ;)  Particularly, never allow complex data types to contain references to other complex data types, that prevents reference loops which are *the* problem requiring complex garbage collectors.  I haven't chosen this for my comparatively inefficient design, I've chosen to make all data structures immutable; if you want to change something, you have to copy the structure.  That way, it's impossible for a structure to contain a reference to itself because the structure becomes immutable before the public reference to it exists.  This very much goes against the grain, I've been exploring every other way of doing it, but I figure if it's good enough for high finance it ought to be good enough for me.  I wonder if it might actually be good enough for OpenSim.  Maybe I'll run some experiments comparing scale, but my system probably won't be ready for that for a long time yet.  My health isn't
 helping me get on with it.
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: use of C# in scripts

Asaff Belfer
In reply to this post by Serendipity Seraph-2
It's a pitty there is no alternative to LSL or maybe a way to use an
"enhanced" LSL which uses better stuctures.

It seems like LSL is aiming to the lowest common factor with the concept
that not everyone is a programmer so it should be accessible to those who
are not.

Asaff


On Mon, Feb 25, 2019 at 8:06 PM Jeff Kelley <[hidden email]> wrote:

> At 1:13 PM -0700 2/20/19, Serendipity Seraph wrote:
>
> >I have run into some grids that are worried by a reported lack of
> >limitation on what C# classes and methods can be called.   Does anyone
> have
> >more detail on this?  It doesn't seem to me that putting in a script
> >scanner that would limit what calls to C# can and cannot go through would
> >be all that difficult.    So is the problem at the least over-inflated?
> Is
> >the concern out of date or misplaced?
>
>
> I did some C# scripting years ago (computing, displaying black body
> spectra in real time). Speed boost over LSL was x10.
>
> Speed gain is much smaller today. Although i can no longer execute
> the C# version, the LSL version which ran in 1.8s in 2011 is now
> around a half second.
>
> I also did some UDP communication, now replaced with HTTP which can
> be awesomely fast.
>
> The pain of LSL is still lack of data structures and modularity.
>
> And it is a huge pain.
>
>
> -- Jeff
>
>
>
> _______________________________________________
> Opensim-users mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: use of C# in scripts

AJLDuarte
Hi,

     Yengine does have a "enhanced" LSL mode, just needs a bit more
cleanup to be documented.

regards,

     Ubit

On 25-Feb-19 18:14, Asaff Belfer wrote:

> It's a pitty there is no alternative to LSL or maybe a way to use an
> "enhanced" LSL which uses better stuctures.
>
> It seems like LSL is aiming to the lowest common factor with the concept
> that not everyone is a programmer so it should be accessible to those who
> are not.
>
> Asaff
>
>
> On Mon, Feb 25, 2019 at 8:06 PM Jeff Kelley <[hidden email]> wrote:
>
>> At 1:13 PM -0700 2/20/19, Serendipity Seraph wrote:
>>
>>> I have run into some grids that are worried by a reported lack of
>>> limitation on what C# classes and methods can be called.   Does anyone
>> have
>>> more detail on this?  It doesn't seem to me that putting in a script
>>> scanner that would limit what calls to C# can and cannot go through would
>>> be all that difficult.    So is the problem at the least over-inflated?
>> Is
>>> the concern out of date or misplaced?
>>
>> I did some C# scripting years ago (computing, displaying black body
>> spectra in real time). Speed boost over LSL was x10.
>>
>> Speed gain is much smaller today. Although i can no longer execute
>> the C# version, the LSL version which ran in 1.8s in 2011 is now
>> around a half second.
>>
>> I also did some UDP communication, now replaced with HTTP which can
>> be awesomely fast.
>>
>> The pain of LSL is still lack of data structures and modularity.
>>
>> And it is a huge pain.
>>
>>
>> -- Jeff
>>
>>
>>
>> _______________________________________________
>> Opensim-users mailing list
>> [hidden email]
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>>
> _______________________________________________
> Opensim-users mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: use of C# in scripts

Serendipity Seraph-2
In reply to this post by Ethan Gardener
AFAIK the JVM garbage collection is as efficient as Lisp garbage
collection.  In fact some of the same people worked on both.  And much of
this tech was used in the C# underlying CLR as well.  So I doubt very much
that GC is a critical issue, especially in small opensim scripts.

On Sun, Feb 24, 2019 at 4:00 AM Ethan Gardener <[hidden email]> wrote:

> On Sat, Feb 23, 2019, at 8:11 PM, Dr Ramesh Ramloll wrote:
> > I think the assumption that C# should work only in closed secure
> > environments kind of narrows down the application space by quite a bit,
> > like 90% or more.
>
> Yeah.  It narrows it down to about the same space as custom modules, so
> why not write them instead?
>
> This is one area where I wish OpenSim had branched out a bit; adding other
> languages, but I guess there was no-one to work on it.  I wasn't up to the
> task myself, as much as I wished I was.  Making a safe interpreter is
> non-trivial anyway.  Lately, I've been looking at one of the problems,
> avoiding memory leaks (which could lead to a denial of service attack or
> possibly an overflow exploit).  This alone is not at all easy to solve
> efficiently.  It would be better if modern computers descended from the
> Lisp Machines of the 1980s, they had hardware support for automatic garbage
> collection, but instead we have virtual memory schemes which make it hard
> for garbage collectors to work efficiently.  (I don't think anyone really
> wants to pay for the extra bits this needs.  The cost of memory was a huge
> limiting factor through the '80s and much of the '90s, and remains a little
> bit of a problem today.)
>
> I can solve my problems with a relatively inefficient design, but that
> would be ridiculous in an environment where a single simulator may have to
> run thousands of scripts.  I could hypothetically write a full-blown
> garbage collector, but it's not worth it because such garbage collectors
> are notoriously prone to bugs, and *still* have efficiency problems.
> Garbage collectors are one of those things which exponentially approach
> infinite complexity as they approach correctness and efficiency.
>
> Is a simple, efficient design possible?  Yes... if you limit the possible
> data structures.  ;)  Particularly, never allow complex data types to
> contain references to other complex data types, that prevents reference
> loops which are *the* problem requiring complex garbage collectors.  I
> haven't chosen this for my comparatively inefficient design, I've chosen to
> make all data structures immutable; if you want to change something, you
> have to copy the structure.  That way, it's impossible for a structure to
> contain a reference to itself because the structure becomes immutable
> before the public reference to it exists.  This very much goes against the
> grain, I've been exploring every other way of doing it, but I figure if
> it's good enough for high finance it ought to be good enough for me.  I
> wonder if it might actually be good enough for OpenSim.  Maybe I'll run
> some experiments comparing scale, but my system probably won't be ready for
> that for a long time yet.  My health isn't
>  helping me get on with it.
> _______________________________________________
> Opensim-users mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: use of C# in scripts

Serendipity Seraph-2
As a software engineer the things that deeply bug me about LSL include:

1) no real way to get reuse vs copy and paste where needed.  Major blow to
possible efficiency gains of not having multiple copies and to
maintainability.  No import/include or library concept or support.

2) almost no real data structures  and no way to roll your own.  Yeah you
can do 1970s era hacks sort of.


On Tue, Feb 26, 2019 at 12:24 PM Serendipity Seraph <[hidden email]>
wrote:

> AFAIK the JVM garbage collection is as efficient as Lisp garbage
> collection.  In fact some of the same people worked on both.  And much of
> this tech was used in the C# underlying CLR as well.  So I doubt very much
> that GC is a critical issue, especially in small opensim scripts.
>
> On Sun, Feb 24, 2019 at 4:00 AM Ethan Gardener <[hidden email]>
> wrote:
>
>> On Sat, Feb 23, 2019, at 8:11 PM, Dr Ramesh Ramloll wrote:
>> > I think the assumption that C# should work only in closed secure
>> > environments kind of narrows down the application space by quite a bit,
>> > like 90% or more.
>>
>> Yeah.  It narrows it down to about the same space as custom modules, so
>> why not write them instead?
>>
>> This is one area where I wish OpenSim had branched out a bit; adding
>> other languages, but I guess there was no-one to work on it.  I wasn't up
>> to the task myself, as much as I wished I was.  Making a safe interpreter
>> is non-trivial anyway.  Lately, I've been looking at one of the problems,
>> avoiding memory leaks (which could lead to a denial of service attack or
>> possibly an overflow exploit).  This alone is not at all easy to solve
>> efficiently.  It would be better if modern computers descended from the
>> Lisp Machines of the 1980s, they had hardware support for automatic garbage
>> collection, but instead we have virtual memory schemes which make it hard
>> for garbage collectors to work efficiently.  (I don't think anyone really
>> wants to pay for the extra bits this needs.  The cost of memory was a huge
>> limiting factor through the '80s and much of the '90s, and remains a little
>> bit of a problem today.)
>>
>> I can solve my problems with a relatively inefficient design, but that
>> would be ridiculous in an environment where a single simulator may have to
>> run thousands of scripts.  I could hypothetically write a full-blown
>> garbage collector, but it's not worth it because such garbage collectors
>> are notoriously prone to bugs, and *still* have efficiency problems.
>> Garbage collectors are one of those things which exponentially approach
>> infinite complexity as they approach correctness and efficiency.
>>
>> Is a simple, efficient design possible?  Yes... if you limit the possible
>> data structures.  ;)  Particularly, never allow complex data types to
>> contain references to other complex data types, that prevents reference
>> loops which are *the* problem requiring complex garbage collectors.  I
>> haven't chosen this for my comparatively inefficient design, I've chosen to
>> make all data structures immutable; if you want to change something, you
>> have to copy the structure.  That way, it's impossible for a structure to
>> contain a reference to itself because the structure becomes immutable
>> before the public reference to it exists.  This very much goes against the
>> grain, I've been exploring every other way of doing it, but I figure if
>> it's good enough for high finance it ought to be good enough for me.  I
>> wonder if it might actually be good enough for OpenSim.  Maybe I'll run
>> some experiments comparing scale, but my system probably won't be ready for
>> that for a long time yet.  My health isn't
>>  helping me get on with it.
>> _______________________________________________
>> Opensim-users mailing list
>> [hidden email]
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>>
>
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: use of C# in scripts

Serendipity Seraph-2
javascript and embedded V8 engine?  Particularly something node-ish with
easy of protocol handling, event handling, async event loop at its core
seems very reasonable for handling a LSL event driven scripting needs.  Of
course you can do much the same in async python and some other languages.
  Heve been tempted once or twice to make some hack to get some lisp or
scheme-ish script.   Or for that matter to hack a LSL intrepreter/debugger
or embedded language in same.

On Tue, Feb 26, 2019 at 12:28 PM Serendipity Seraph <[hidden email]>
wrote:

> As a software engineer the things that deeply bug me about LSL include:
>
> 1) no real way to get reuse vs copy and paste where needed.  Major blow to
> possible efficiency gains of not having multiple copies and to
> maintainability.  No import/include or library concept or support.
>
> 2) almost no real data structures  and no way to roll your own.  Yeah you
> can do 1970s era hacks sort of.
>
>
> On Tue, Feb 26, 2019 at 12:24 PM Serendipity Seraph <
> [hidden email]> wrote:
>
>> AFAIK the JVM garbage collection is as efficient as Lisp garbage
>> collection.  In fact some of the same people worked on both.  And much of
>> this tech was used in the C# underlying CLR as well.  So I doubt very much
>> that GC is a critical issue, especially in small opensim scripts.
>>
>> On Sun, Feb 24, 2019 at 4:00 AM Ethan Gardener <[hidden email]>
>> wrote:
>>
>>> On Sat, Feb 23, 2019, at 8:11 PM, Dr Ramesh Ramloll wrote:
>>> > I think the assumption that C# should work only in closed secure
>>> > environments kind of narrows down the application space by quite a bit,
>>> > like 90% or more.
>>>
>>> Yeah.  It narrows it down to about the same space as custom modules, so
>>> why not write them instead?
>>>
>>> This is one area where I wish OpenSim had branched out a bit; adding
>>> other languages, but I guess there was no-one to work on it.  I wasn't up
>>> to the task myself, as much as I wished I was.  Making a safe interpreter
>>> is non-trivial anyway.  Lately, I've been looking at one of the problems,
>>> avoiding memory leaks (which could lead to a denial of service attack or
>>> possibly an overflow exploit).  This alone is not at all easy to solve
>>> efficiently.  It would be better if modern computers descended from the
>>> Lisp Machines of the 1980s, they had hardware support for automatic garbage
>>> collection, but instead we have virtual memory schemes which make it hard
>>> for garbage collectors to work efficiently.  (I don't think anyone really
>>> wants to pay for the extra bits this needs.  The cost of memory was a huge
>>> limiting factor through the '80s and much of the '90s, and remains a little
>>> bit of a problem today.)
>>>
>>> I can solve my problems with a relatively inefficient design, but that
>>> would be ridiculous in an environment where a single simulator may have to
>>> run thousands of scripts.  I could hypothetically write a full-blown
>>> garbage collector, but it's not worth it because such garbage collectors
>>> are notoriously prone to bugs, and *still* have efficiency problems.
>>> Garbage collectors are one of those things which exponentially approach
>>> infinite complexity as they approach correctness and efficiency.
>>>
>>> Is a simple, efficient design possible?  Yes... if you limit the
>>> possible data structures.  ;)  Particularly, never allow complex data types
>>> to contain references to other complex data types, that prevents reference
>>> loops which are *the* problem requiring complex garbage collectors.  I
>>> haven't chosen this for my comparatively inefficient design, I've chosen to
>>> make all data structures immutable; if you want to change something, you
>>> have to copy the structure.  That way, it's impossible for a structure to
>>> contain a reference to itself because the structure becomes immutable
>>> before the public reference to it exists.  This very much goes against the
>>> grain, I've been exploring every other way of doing it, but I figure if
>>> it's good enough for high finance it ought to be good enough for me.  I
>>> wonder if it might actually be good enough for OpenSim.  Maybe I'll run
>>> some experiments comparing scale, but my system probably won't be ready for
>>> that for a long time yet.  My health isn't
>>>  helping me get on with it.
>>> _______________________________________________
>>> Opensim-users mailing list
>>> [hidden email]
>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>>>
>>
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: use of C# in scripts

Serendipity Seraph-2
Also been tempted by idea of writing in whatever language I like and
targeting vanilla LSL.  :)


On Tue, Feb 26, 2019 at 12:33 PM Serendipity Seraph <[hidden email]>
wrote:

> javascript and embedded V8 engine?  Particularly something node-ish with
> easy of protocol handling, event handling, async event loop at its core
> seems very reasonable for handling a LSL event driven scripting needs.  Of
> course you can do much the same in async python and some other languages.
>   Heve been tempted once or twice to make some hack to get some lisp or
> scheme-ish script.   Or for that matter to hack a LSL intrepreter/debugger
> or embedded language in same.
>
> On Tue, Feb 26, 2019 at 12:28 PM Serendipity Seraph <
> [hidden email]> wrote:
>
>> As a software engineer the things that deeply bug me about LSL include:
>>
>> 1) no real way to get reuse vs copy and paste where needed.  Major blow
>> to possible efficiency gains of not having multiple copies and to
>> maintainability.  No import/include or library concept or support.
>>
>> 2) almost no real data structures  and no way to roll your own.  Yeah you
>> can do 1970s era hacks sort of.
>>
>>
>> On Tue, Feb 26, 2019 at 12:24 PM Serendipity Seraph <
>> [hidden email]> wrote:
>>
>>> AFAIK the JVM garbage collection is as efficient as Lisp garbage
>>> collection.  In fact some of the same people worked on both.  And much of
>>> this tech was used in the C# underlying CLR as well.  So I doubt very much
>>> that GC is a critical issue, especially in small opensim scripts.
>>>
>>> On Sun, Feb 24, 2019 at 4:00 AM Ethan Gardener <[hidden email]>
>>> wrote:
>>>
>>>> On Sat, Feb 23, 2019, at 8:11 PM, Dr Ramesh Ramloll wrote:
>>>> > I think the assumption that C# should work only in closed secure
>>>> > environments kind of narrows down the application space by quite a
>>>> bit,
>>>> > like 90% or more.
>>>>
>>>> Yeah.  It narrows it down to about the same space as custom modules, so
>>>> why not write them instead?
>>>>
>>>> This is one area where I wish OpenSim had branched out a bit; adding
>>>> other languages, but I guess there was no-one to work on it.  I wasn't up
>>>> to the task myself, as much as I wished I was.  Making a safe interpreter
>>>> is non-trivial anyway.  Lately, I've been looking at one of the problems,
>>>> avoiding memory leaks (which could lead to a denial of service attack or
>>>> possibly an overflow exploit).  This alone is not at all easy to solve
>>>> efficiently.  It would be better if modern computers descended from the
>>>> Lisp Machines of the 1980s, they had hardware support for automatic garbage
>>>> collection, but instead we have virtual memory schemes which make it hard
>>>> for garbage collectors to work efficiently.  (I don't think anyone really
>>>> wants to pay for the extra bits this needs.  The cost of memory was a huge
>>>> limiting factor through the '80s and much of the '90s, and remains a little
>>>> bit of a problem today.)
>>>>
>>>> I can solve my problems with a relatively inefficient design, but that
>>>> would be ridiculous in an environment where a single simulator may have to
>>>> run thousands of scripts.  I could hypothetically write a full-blown
>>>> garbage collector, but it's not worth it because such garbage collectors
>>>> are notoriously prone to bugs, and *still* have efficiency problems.
>>>> Garbage collectors are one of those things which exponentially approach
>>>> infinite complexity as they approach correctness and efficiency.
>>>>
>>>> Is a simple, efficient design possible?  Yes... if you limit the
>>>> possible data structures.  ;)  Particularly, never allow complex data types
>>>> to contain references to other complex data types, that prevents reference
>>>> loops which are *the* problem requiring complex garbage collectors.  I
>>>> haven't chosen this for my comparatively inefficient design, I've chosen to
>>>> make all data structures immutable; if you want to change something, you
>>>> have to copy the structure.  That way, it's impossible for a structure to
>>>> contain a reference to itself because the structure becomes immutable
>>>> before the public reference to it exists.  This very much goes against the
>>>> grain, I've been exploring every other way of doing it, but I figure if
>>>> it's good enough for high finance it ought to be good enough for me.  I
>>>> wonder if it might actually be good enough for OpenSim.  Maybe I'll run
>>>> some experiments comparing scale, but my system probably won't be ready for
>>>> that for a long time yet.  My health isn't
>>>>  helping me get on with it.
>>>> _______________________________________________
>>>> Opensim-users mailing list
>>>> [hidden email]
>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>>>>
>>>
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: use of C# in scripts

Haravikk
In reply to this post by Serendipity Seraph-2


> On 26 Feb 2019, at 19:28, Serendipity Seraph <[hidden email]> wrote:
>
> As a software engineer the things that deeply bug me about LSL include:
>
> 1) no real way to get reuse vs copy and paste where needed.  Major blow to
> possible efficiency gains of not having multiple copies and to
> maintainability.  No import/include or library concept or support.
>
> 2) almost no real data structures  and no way to roll your own.  Yeah you
> can do 1970s era hacks sort of.

The problem with LSL is that it's just plain shit, to use the correct technical expression; I mean seriously, no proper array but instead we get a linked-list that is fully copied on even minor modifications, thus eliminating all benefits of it being a linked list? So you got both linear access time, bad performance all round AND you can't even add to it efficiently!

I dunno if OpenSim managed to optimise that to use a real linked list behind the scenes but then performance hasn't been such a big issue for me since I'm running lightweight private sims on actually half-decent hardware, but for Second Life itself it's always been a bad joke for, has been now for what, 15 years?

It always bugged me how much it felt like somebody's first year compiler class project that they then just rammed into the first programming job they got, which to our misfortune happened to be Second Life, and we've been stuck with it ever since.

Obviously I get why OpenSim keeps LSL, since it makes it easier for people to port scripts over from SL, but man it's a bad language. There were superior scripting languages 20 years before SL even existed; it has never made any sense why they rolled their own, or didn't even copy elements from actually good languages and APIs. The SL version of LSL is also the only language I'm aware of that has not one, but three broken implementations of base64 XOR; seriously, not one of them is actually correct.


Sorry, that's really just a bit of a rant and not terribly constructive, but man it annoys me.

OpenSim has so many useful capabilities compared to SL but it does still feel like LSL constrains what we can do a bit; I can only imagine how great it'd be to have a proper object oriented API in some other language, but I doubt it's something I'm likely to have time to work on myself.
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: use of C# in scripts

Asaff Belfer
I get your feelings and I think the same that LSL can be better. I've been
in SL only a few years but I can imagine what goes on behind the scene. I
believe it's a struggle to keep such a company afloat as there is a huge
infrastructure to support and a complex system that requires end user
support as many low tech users are using it and tech support is an
expensive resource. Add research and development to it and you'll get a
monster that you need to feed.

As for opensim, I think that a secondary scripting system can be added. If
today you can annotate your code to specify the script language (i.e. c#)
maybe there is a way to set things up so that you could implement other
scripting languages and use that annotation to route the code to the right
compiler.


Asaff


On Wed, Feb 27, 2019 at 12:16 AM Haravikk <[hidden email]> wrote:

>
>
> > On 26 Feb 2019, at 19:28, Serendipity Seraph <[hidden email]>
> wrote:
> >
> > As a software engineer the things that deeply bug me about LSL include:
> >
> > 1) no real way to get reuse vs copy and paste where needed.  Major blow
> to
> > possible efficiency gains of not having multiple copies and to
> > maintainability.  No import/include or library concept or support.
> >
> > 2) almost no real data structures  and no way to roll your own.  Yeah you
> > can do 1970s era hacks sort of.
>
> The problem with LSL is that it's just plain shit, to use the correct
> technical expression; I mean seriously, no proper array but instead we get
> a linked-list that is fully copied on even minor modifications, thus
> eliminating all benefits of it being a linked list? So you got both linear
> access time, bad performance all round AND you can't even add to it
> efficiently!
>
> I dunno if OpenSim managed to optimise that to use a real linked list
> behind the scenes but then performance hasn't been such a big issue for me
> since I'm running lightweight private sims on actually half-decent
> hardware, but for Second Life itself it's always been a bad joke for, has
> been now for what, 15 years?
>
> It always bugged me how much it felt like somebody's first year compiler
> class project that they then just rammed into the first programming job
> they got, which to our misfortune happened to be Second Life, and we've
> been stuck with it ever since.
>
> Obviously I get why OpenSim keeps LSL, since it makes it easier for people
> to port scripts over from SL, but man it's a bad language. There were
> superior scripting languages 20 years before SL even existed; it has never
> made any sense why they rolled their own, or didn't even copy elements from
> actually good languages and APIs. The SL version of LSL is also the only
> language I'm aware of that has not one, but three broken implementations of
> base64 XOR; seriously, not one of them is actually correct.
>
>
> Sorry, that's really just a bit of a rant and not terribly constructive,
> but man it annoys me.
>
> OpenSim has so many useful capabilities compared to SL but it does still
> feel like LSL constrains what we can do a bit; I can only imagine how great
> it'd be to have a proper object oriented API in some other language, but I
> doubt it's something I'm likely to have time to work on myself.
> _______________________________________________
> Opensim-users mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: use of C# in scripts

Ethan Gardener
In reply to this post by Serendipity Seraph-2
On Tue, Feb 26, 2019, at 7:34 PM, Serendipity Seraph wrote:
> javascript and embedded V8 engine?  Particularly something node-ish with
> easy of protocol handling, event handling, async event loop at its core

Caution #1: We need floating point numbers. Javascript freely converting between numbers and strings can produce some very strange-looking floating-point bugs.

Caution #2: Node's own author discovered its design to be a mistake.  He wrote it up, posted it; his post was taken down as "too controversial".  (The hubris and arrogance which builds up around some projects is *horrible!*)  I'm sorry I don't remember details, but part of it was something like, "there's no such thing as non-blocking; using the CPU takes time."  Node's design arose out of a desire to imitate some dangerous hacks a very smart programmer made very carefully to stretch the limits of 90s web servers.  Node was not designed with the same level of skill.
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

LSL could support nested lists

Ethan Gardener
In reply to this post by Haravikk
On Tue, Feb 26, 2019, at 10:16 PM, Haravikk wrote:
> [...] I mean seriously, no proper array but instead we
> get a linked-list that is fully copied on even minor modifications,

I remembered this just as I was falling asleep after my last big email.  Basically, LSL has two ways of preventing reference loops, each of which is quite good enough on its own.  Given that a list is copied on even the smallest of modifications, there's no reason to prevent lists containing list references. There's no way to make a circular reference because each list becomes immutable before its reference can be obtained.  

We could have nested lists as soon as appropriate functions could be designed and implemented.  (Now I think about it, I can't understand why no-one's implemented it before.)


Don't get hung up on it being a linked list, the truth about performance is often very surprising and quite contrary to popular opinion.  For instance, a hash table may spend more time hashing than a linked list would searching.  This was an actual *serious* problem a few years ago with programmers producing terribly slow designs because they thought some techniques were always faster.  It's probably still going on, but I stopped paying attention because it makes me angry.  (Same with the async i/o / node.js hubris.)  In any case, because it's always copied, the actual implementation could be anything.
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: LSL could support nested lists

Haravikk

> On 27 Feb 2019, at 09:05, Ethan Gardener <[hidden email]> wrote:
>
> On Tue, Feb 26, 2019, at 10:16 PM, Haravikk wrote:
>> [...] I mean seriously, no proper array but instead we
>> get a linked-list that is fully copied on even minor modifications,
>
> I remembered this just as I was falling asleep after my last big email.  Basically, LSL has two ways of preventing reference loops, each of which is quite good enough on its own.  Given that a list is copied on even the smallest of modifications, there's no reason to prevent lists containing list references. There's no way to make a circular reference because each list becomes immutable before its reference can be obtained.  
>
> We could have nested lists as soon as appropriate functions could be designed and implemented.  (Now I think about it, I can't understand why no-one's implemented it before.)

That's an interesting point, though strictly speaking I'm not sure reference loops are something LSL ever needed to worry about; if you use it to create a memory leak in your script then it only ever affects that script (runs out of memory and halts), and traversal loops can only becomes an infinite loop if you also use recursion to do-so, but again it only affects the one script which is throttled and currently would then run out of stack space and halt.

So while it's useful not to have this as a possibility I'm not sure I'm convinced it was an intentional decision; after all, without the ability to add lists, plus an llList2NestedList() function to retrieve them it was never going to be a problem anyway. Even if it did all that was really required was a warning "don't put lists inside themselves, ya dafty", just like divide by zero and other things you just have to learn.

> Don't get hung up on it being a linked list, the truth about performance is often very surprising and quite contrary to popular opinion.  For instance, a hash table may spend more time hashing than a linked list would searching.  This was an actual *serious* problem a few years ago with programmers producing terribly slow designs because they thought some techniques were always faster.  It's probably still going on, but I stopped paying attention because it makes me angry.  (Same with the async i/o / node.js hubris.)  In any case, because it's always copied, the actual implementation could be anything.

Sure, but there are only really two main advantages to linked-lists, the first being that they don't require contiguous memory (which makes some sense in a very constrained memory environment) the second is that adding or removing the head of a linked list is very fast (same with the tail if the list includes a reference to that as well), which can make them good for use as queues in certain scenarios. There are also weirder things you can do with them like constant time appends (add one linked list onto the tail of another) or certain sorts that swap entire chunks of the list around but none of these apply to LSL either.

The big problem with the decisions around lists in LSL is that the fragmentation problem is only really a problem because of the linked lists in the first place, and under Mono I don't believe it's a problem at all (total memory used is just a value, there's no true stack heap collision, you can verify this using strings since they're contiguous). Meanwhile the design decision around copying meant that the low overhead add/remove to head/tail was eliminated entirely.

But yeah, you're right that there's no real reason that OpenSim can't just implement "lists" however it wants behind the scenes, even using arrays, since none of the functions enforce the use of a list rather than any indexed container, ignoring the naming, and it's just a compilation detail. All a user would see is faster access and less overhead, depending upon how array sizing was implemented (e.g- double in size up to 64, then add to size in increments of 64 to keep things sane, rather than always doubling as is common).

I have always been interested in the technical aspects of it all, but it's not easy to shake the feeling that every question asked during the design of LSL was answered incorrectly 😏
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
12