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 <seren.ser...@gmail.com> 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 < > seren.ser...@gmail.com> 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 < >> seren.ser...@gmail.com> 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 <eeke...@fastmail.fm> >>> 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 >>>> Opensim-users@opensimulator.org >>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users >>>> >>> _______________________________________________ Opensim-users mailing list Opensim-users@opensimulator.org http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users