|Anonymous | Login | Signup for a new account||2021-01-17 05:13 PST|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008846||opensim||[MISC] Compiling / Building||public||2021-01-03 12:54||2021-01-07 06:24|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Platform||window||Operating System||window||Operating System Version||10 (x64)|
|Target Version||Fixed in Version|
|Description||As I have verified today, thanks to the contribution of djphil It is still possible to use another alternative language for scripts in Opensim.|
However, the options do not appear in the configuration files, for example opensim.ini.
This situation suggests that in future versions this alternative may completely disappear.
In my opinion, the possibility of being able to use more compilation languages is positive for OpenSim. Although it can also be dangerous, however, it is optional that each user must assume responsibility for whether or not to use.
I think it is important for users to know the future of this utility because some projects may depend on it
what is the future of these options ?.
Will other languages be used in future versions?
|Additional Information||Meanwhile, been looking online and found very few examples|
Do you know somewhere to consult more examples? If not, can we share here?
|Git Revision or version number|
|Run Mode||Standalone (1 Region)|
hey djphil ... I used the "issue resolved" option and then I couldn't reply.
In my previous post,
You ask me if I know the book format, do you mean the extension? .txt?
I would also be in favor of this option not being deleted and silk maintained.
Yes I was talking about the extension for the books files used by this Alexandria project.
|LSL is the only supported language.|
Robert Adams (administrator)
Getting more scripting languages is possible but there needs to be a developer willing to make it happen. Over the years there have been several attempts to include a language and solve all the security and shared resource problems.
At the moment, only LSL (implemented with XEngine and YEngine) is worked on. There are the hooks to allow enabling C# but you'd have deal with the lack of security and resource management and it probably fails when region crossing, etc.
it is not possible to secure code created by languages other the lsl, the way Xengine or MRM did. The remains of those options will be removed.
And there is no point on doing so. Scripts are specialized code that must be restricted in scope.
Other engines (unity for example) that do use c# as script language do run it on a dedicated embedded environment, so within well defined boundaries. (in fact it is converted to c++).
On Yengine we did add some languages extensions, and that is a reasonable path , even so creating more incompatibilities between regions running diferent versions.
|djphill...I use all of them with .txt format, the classics that can be created in the notepad that windos brings by default. However, the script is capable of reading files in other formats such as html or xml, but I am not interested because they are read with the tags.|
Ok thanks for the information.
I found the idea interesting but I haven't tested anything.
Maybe one day I will do something similar in full LSL / OSSL
But first I have to test to see if it's really interesting.
Thanks again ;-)
If the aim is to share information between scripts there are ways to handle this in ways that don't require additional functionality to be added.
There are already functions for writing notecards and also functions to deliver information from one object to another without using heavy listeners.
Look up on osMessageObject, which causes a dataserver event on the other end.
You can create a "database" script that listens to data requests and delivers them back via MessageObject with very little overhead.
Not only does this work rather well to share information, it is also compatible directly without the need for a special OpenSim version.
In this case I think it is more about using external rrmrnts and infusing them into opensim.
As you know lsl / ossl curiously lacks the means to store data.
In addition, using external elements also facilitates the simultaneous use of data either on several regions, or on several grids, or both.
But again I haven't tested anything so I may be completely wrong about what exactly is and what the Alexandria project does.
Please do not remove the ability to compile C#, except if it stands in the way of future evolutions.
It is the only script dialect supporting structured data. By forcing scripters to use clumsy llLists, you will discourage those involved in - for example - science education. Try to code a fast Fourier Transform with lists, or any serious numerical computation, and give me news.
This is not using opensimulator as a replacement for a workstation. But as an interactive learning bench (think the defunct Java science applets on the web).
What opensimulator is for should be let to the users, leaving choices open rather than closing them, and free from the Second Life-clone perspective. Including experimenting with unsupported features.
If C# must die because it is extra work to keep it alive, so be it. Otherwise, it should not be a decision imposed on users. A responsible scripter understands the security issues and will not deploy C#t on a public grid. Only in a private, managed and secured environment.
c# should not be used except on very closed and controlled environments
It made sense with XEngine basically because Xengine does convert LSL to c#, and final compile done by .net compiler.
in fact other .net languages where supported.
This is a big security risk, just not possible to prevent under .net
YEngine does direct compile (to IL ) so it is LSL only
but can have extensions.
xmr had some, just the way they are done is not very appealing, so still waiting..
A well documented plugin interface for those who need would be nice. By writing some C# code one could implement its own specific types and functions.
Much like in xmr, scripters could then simply add yoptions <plugin>; to the script in order to use the extensions provided by the plugin.
|2021-01-03 12:54||nikolsy||New Issue|
|2021-01-03 12:57||nikolsy||Note Added: 0037454|
|2021-01-03 12:58||nikolsy||Tag Attached: C#|
|2021-01-03 12:58||nikolsy||Tag Attached: CompileLanguag|
|2021-01-03 13:02||djphil||Note Added: 0037455|
|2021-01-03 14:59||UbitUmarov||Note Added: 0037456|
|2021-01-04 07:37||Robert Adams||Note Added: 0037457|
|2021-01-04 08:26||UbitUmarov||Note Added: 0037458|
|2021-01-06 07:23||nikolsy||Note Added: 0037468|
|2021-01-06 08:13||djphil||Note Added: 0037469|
|2021-01-06 12:54||tampa||Note Added: 0037470|
|2021-01-06 13:00||djphil||Note Added: 0037471|
|2021-01-06 13:02||JeffKelley||Note Added: 0037472|
|2021-01-06 19:58||UbitUmarov||Note Added: 0037474|
|2021-01-07 06:24||piusnoel||Note Added: 0037475|
|Copyright © 2000 - 2012 MantisBT Group|