Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003187opensim[MISC] Compiling / Buildingpublic2009-02-17 20:022009-03-11 11:58
Assigned Tomelanie 
PlatformOperating SystemOperating System Version
Product Version 
Target VersionFixed in Version 
Summary0003187: popular list memory saving hack does not work in LSL
DescriptionThe code below produces different results in OpenSim than in SecondLife:

        list foo = [ "foo" ];
        llSay(0, (string) llGetListLength(foo));
        foo = (foo=[]) + foo + [ "bar" ];
        llSay(0, (string) llGetListLength(foo)); // 1 in OpenSim, 2 in SL
TagsNo tags attached.
Git Revision or version number
Run ModeStandalone (1 Region) , Standalone (Multiple Regions) , Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)
Physics EngineBasicPhysics, PhysicsOfSimplicity, ODE, BulletX, PhysX, Other
Script Engine
EnvironmentUnknown, Mono / Linux32, Mono / Linux64, Mono / Windows, Mono / OSX, .NET / Windows32, .NET / Windows64
Mono VersionNone
Attached Filespatch file icon error.patch [^] (3,145 bytes) 2009-02-20 19:06 [Show Content]
patch file icon warning.patch [^] (11,653 bytes) 2009-02-21 15:46 [Show Content]
patch file icon warning2.patch [^] (11,257 bytes) 2009-02-22 13:30 [Show Content]
patch file icon multiplewarningfix.patch [^] (1,300 bytes) 2009-02-23 22:03 [Show Content]

- Relationships
related to 0001863closed Three minor script compilion errors 

-  Notes
mikem (developer)
2009-02-17 20:16
edited on: 2009-02-17 20:18

This is a known issue. Please see commit r5718[1] and issue 1863[2].

[1] [^]
[2] [^]

melanie (administrator)
2009-02-17 21:16

There are no plans to reproduce this SL behavior.
DoranZemlja (reporter)
2009-02-17 21:49

I've hit this sort of thing a couple of times now and I find it very frustrating. My expectation is that LSL in OpenSim will behave exactly as LSL in SecondLife.

I can understand there being bugs and this not being true. Luckily I'm a C# developer in the real world, so I can dig in and at least get a clue as to what's going on, and in some cases offer patches. I have real pity for folks coming at this with only an LSL background, however. They're going to have no clue at all.

The idea that there are no plans to address certain issues, however, is simply baffling. The average LSL-only scripter who hits incompatibilities like this may just get frustrated and walk away. I'm pretty close myself.

Is there a document that lists all known LSL incompatability issues that OpenSim has no plans to address? Or am I going to bang my head against a wall for a few hours for each one of these until I discover them and then work to weed each one out of all my LSL code?
WiLLuMPJuH Huisman (reporter)
2009-02-18 01:21
edited on: 2009-02-18 01:37

Please see [^] for more about the current status of implemented LSL functions in OpenSim.

Doran ... for your consideration about the 'need in OpenSim' and 'popular functions in LSL'. Undoubtedly your patches are welcomed and appreciated. I cannot promise you though you will not hit limitations to your expectation of full compatibility with LSL. OpenSim is alpha and as you know under heavy development.

I am no developer and too dumb for C#, but am least schocked. This server code is foremost constructed by libraries from the SL - client , so it's kind of a reverse engeneering. The code is not an exact copy of Lindenlab' server software. So many code essential for LSL-function had / has to be 'rediscovered' and implemented by need. Ask anybody of the devs about LSL functions , like, a year ago and you will hear other stories of stuff lacking. It's an ongoing proces , I think. With the priorities the devs take, the path may be different from expectation of 'hardcore' Second Life - users.


melanie (administrator)
2009-02-18 04:53

The server code has absolutely NO connection to the client. There is certainly NO code from the client in it, we made sure of that.
OpenSim is 100% original work of it's authors, based on reverse engineering and cleanrooming techniques.

The issue here is about a hack, a behavior that was not even a design feature for LSL and has never been documented as a language feature by Linden Labs.

It exploits a quirk in the LSO engine's allocation behavior which we never had. We also don't suffer from the memory bloat issue that makde it necessary in the first place.

This was discussed once and the consensus reached between those present was to not duplicate this bug.

This "hack" will therefore have to be removed from user scripting.
DoranZemlja (reporter)
2009-02-18 06:26

melanie --

While considered a "hack", that practice was actively encouraged by LL for a very long period of time. Indeed, it is still mentioned on [^] ! It is likely to be in a large percentage of scripts out there. If your goal is compatibility with SecondLife, then you have to support it.

At the very least I take issue with the attitude in your response. I'd like to think that, if I were to produce a patch that addressed the issue, it would be reviewed and considered. Your response does not even leave that door open, and puts the onus of compatibility completely on hapless LSL scripters.
DoranZemlja (reporter)
2009-02-18 06:39

WiLLuMPJuH Huisman --

Please show me where in that link that it mentions that the list memory hack is not and never will be implemented in OpenSim LSL.

Any page which begins "This page is always under construction and perpetually being updated, don't consider the info here to be 100% dead on." is not likely to be taken seriously.

I'm looking for a serious document that lists the OpenSim/SecondLife LSL incompatibilities. My point is that we should not torture those who want to port their code by making them slog through an hour of debugging only to discover that 'foo = (foo=[]) + foo + [ "bar" ]' is broken and will never be fixed. We want to make OpenSim easier to use, not harder.

As an aside, can someone explain to me what "the recent LibSL fiasco" is?
eekee (reporter)
2009-02-18 07:04

Doran: It's usually terribly bad practice to make comments on a specific issue that don't pertain exactly to that issue. That's what mailing lists are for.

And there I go, doing the same myself. :p
melanie (administrator)
2009-02-18 08:52

If you were to provide a patch that allows that hack to behave like SL, we would most certainly consider it. If it doesn't break anything else or significantly impacts the quality of the generated code or performance of the script, it will be included in OpenSim.
If we had no intention to ever accept any input on this, this issue report would be closed. However, it is of very low importance, since it's so easily fixed. Most scripts have to be reworked for OpenSim anyway.
DoranZemlja (reporter)
2009-02-20 19:08

patch generates a compile error for any LSL assignment statement that includes other assignment statements to the same variable. This alerts the end user that something in the code needs to change, rather than silently creating bad code with unexpected results.
dahlia (administrator)
2009-02-20 23:34

I'm not sure this should prevent successful compilation and produce an error, as the syntax of the list hack appears to be a legal syntax to those who are accustomed to c like languages. Likewise, if I were to look at the code in the example, I would expect the list foo to contain a single string element, [ "bar" ]. It's the LL implementation which is confusing to many who are learning LSL scripting as one may expect the list foo to be initialized to an empty list as the parenthetical expression should be evaluated prior to concatenation. I would thus suggest that if you want to submit a patch that does not address the problem by making the OpenSim scripting subsystem behave in the same manner, that a warning message would be preferable to an error. Something along the lines of "Warning: Ugly list hack detected which may not produce the results you were expecting"
DoranZemlja (reporter)
2009-02-21 00:17

Dahlia --

As far as I can tell, the existing architecture does not support "warnings". Maybe I'm wrong and someone can point it out to me.

IMHO, erroring out is FAR more preferable to producing bad code.
melanie (administrator)
2009-02-21 03:20

I really don't like the idea of erroring out. It can serve as an aid to porting scripts from SL, by finding what may be a nonobvious error to many, but it prevents a language feature of OpenSim being used by scripts written for OpenSim. As a scripter, I know I use every trick in the book, and some that aren't, to get what I want from the subsystem I work with.
So, I would like to ses something less severe than an error.
Having some sort of mechanism along these lines is not a bad thing, though, just the what the proper response would be needs to be looked into.
mikem (developer)
2009-02-21 04:44

I wonder if a standalone "script checker" tool that uses this patch can be developed to check scripts being migrated from SL for the list hack?
DoranZemlja (reporter)
2009-02-21 08:31

mikem -

It's not just the list hack that causes problems. Any statement that relies on right to left evaluation will cause problems. The list hack is just one example of this. Here's another:

integer l;
integer n;
l = (n=3) + (n=4) + (n=5);

This behaves very differently in SL LSL than in OS LSL. Since LSL was born in SL, I consider it the gold standard of how an LSL implementation should behave. If OS is not going to behave that way, the user should be alerted to save them from hours of tortuous debugging.
DoranZemlja (reporter)
2009-02-21 08:45

melanie --

I'm not sure I understand your statement about "prevent[ing] a language feature of OpenSim being used by scripts". I don't consider OpenSim's behavior in these cases as a feature. LL invented LSL, and part of the specification is the right to left evaluation that makes things like the list hack behave the way they do (see previous note). OpenSim's behavior in this case is a bug, not a feature. The great majority of people doing LSL in OpenSim are going to be people migrating their scripts from SL. In this case, they are going to expect that LSL behavior, and be surprised when they don't get it. People writing scripts specifically for OpenSim are far more likely to use CS, VB, or one of the N other (more sane and familiar) languages OS supports.
melanie (administrator)
2009-02-21 10:00


LSL may have been invented by LSL, but we do not have LSL. We have OSSL, which differs in places. You propose to totally lock up a suntactically correct construct for the benefit of some of the scripts that could be brought over from SL.
The other languages cannot currently be made safe, so they can't be made available for public scripting.

We agree in that the user should be warned of potential ill side effects, but I am firmly -1 on preventing it's use.

Any patch or external tool that will warn the user will be very helpful. Erroring out is not an option.
DoranZemlja (reporter)
2009-02-21 10:40

melanie --

Thank you for correcting my misunderstanding. I plan to have a different patch for this issue by Monday.
DoranZemlja (reporter)
2009-02-21 15:47

please disregard error.patch

warning.patch introduces compile time warnings, and generates warnings during multiple assignments to the same variable in a single statement.
melanie (administrator)
2009-02-21 18:40

Thank you for understanding out poin tof view. I will test this shortly and apply if it works.
DoranZemlja (reporter)
2009-02-22 07:22

To be clear, I understand, but I do not agree. I think a lack of strict adherence to the LSL specifications will turn away many serious LSL programmers, which will lead to a rate limiting effect of good scripts moving from SL into OS.
melanie (administrator)
2009-02-22 07:30

Any _good_ LSL programmer will accept and embrace the differences and leverage them in different ways.
Anyone who just expects to take freebie script source and copy/paste to OpenSim will have issues.

But OpenSim is not an adjunct to LL, not a "second SL" to have cheap land for experiments, then take it to the "real" world (SL). OpenSim is something of it's own, independent and different. We don't want to BE SL.
DoranZemlja (reporter)
2009-02-22 10:26

"We don't want to BE SL."

And I think that was the core of my misunderstanding. Whether you intend to or not, using the SL client protocol, and having lots of source code with references to "LSL", and adopting a large portion of their paradigm and nomenclature (256x256 "regions", etc...), you set a strong expectation that things will be like SL. When you set expectations like that, you're going to see frustrated people. Like me.

I wonder, if that statement is true, why you have clung as closely as you have to SL's paradigm. If you truly wanted to break the mold, there are so many things you could have done different from and better than SL.

To me, the really neat thing about open source software is that people will inevitably use it in ways you never expected, whether you like it or not. Regardless of how you feel about people who want "to have cheap land for experiments", people will use OpenSim for precisely that.

By the way, you used "freebie" in a pejorative sense, which I find really amusing coming from an open source developer. Just because something is given away for free, doesn't mean it's worthless. And I'm certain that not everyone running complex free software (like say, the Linux kernel) is a _good_ programmer and can instantly debug every problem they come across.

You also implied that I wasn't a _good_ LSL programmer because I did not "accept and embrace the differences and leverage them in different ways". I disagree completely. It is precisely BECAUSE I am a good LSL programmer that I even noticed the differences at all. It is precisely BECAUSE I am a good programmer that I was able to trace down their root causes, and even offer patches, some of which you've accepted. For reference, I have no desire to "leverage the differences" between OS and SL. My desire is to avoid working my butt off porting a ton of scripts to OS. As a script author, ideally I'd like my scripts to work in both environments, without modification.

So like I said, I understand, but I do not agree, and I think your attitude is going to drive away otherwise good programmers who really could contribute something worthwhile.
melanie (administrator)
2009-02-22 11:20
edited on: 2009-02-22 11:21

Actually, we are on a way to diverge and eventually depart from the SL straitjacket. It was a requirement to use the one exiting full featured client, and that is why many things snuck in that are Linden-ism. They will be removed/deemphasized over time.
we have OSSL, not LSL. We implement a LSL API. We did not implement the LSL language specification completely, but instead built on it's similarities to C(++,#) to get it to work.
OpenSim, is not SL, it doesn't want to be SL and it doesn'encourage people to think it is SL.
And i used the word freebie in the SL sense, where it commonly describes a giveaway item of low quality.
Finally, we did intend, and have managed to get a good base of scripts and scripters into OpenSim by being nearly compatible to SL.
We can not invest the person-hours it takes to fix up quirks and duplicate bugs.

Now, a RTL vs. LTR eval order is such a dfference. Each allows multiple assignments, and each produces different results.

Making our LSL evaluate RTL would be one thing, and if you could, we'd accept it gladly. But disallowing multiple assignments under either language's semantics completely is not adding something; it takes away. It is really hard totake away things from OpenSim.

So, that is my position. I am not intending to drive away anyone. But we're also not intending to be SL. Actually, some SL-Like things may change, fall into disuse, get superseded or break. Maybe.

Gigs (reporter)
2009-02-22 11:30

I'm a serious LSL programmer (or at least was one for a while). I would not want to see the incorrect behavior of LL's LSL emulated here, so I'm with melanie on this one.

Like melanie points out, the fantasy of being able to directly drop in scripts with absolutely no modification is pretty much never going to happen. LL faced the same thing when they themselves moved to Mono. They thought for a while that they would be able to get 100% compatibility; that never happened, which is why you still need to recompile the script manually instead of them triggering an automatic migration.
DoranZemlja (reporter)
2009-02-22 11:36

Gigs -

You are incorrect re: the reason for not triggering automatic migration to mono in SL. The reason that they didn't had to do with maintaining state in running scripts, not any inherent incompatibility between the old compiler and the mono compiler. As a matter of fact they went through great lengths to ensure that things like the list hack and RTL evaluation worked in Mono.
DoranZemlja (reporter)
2009-02-22 11:37

melanie --

Like I said, thank you for correcting my misunderstanding.

The new patch (warning.patch) detects the condition and generates a warning, nothing more.
cfk (administrator)
2009-02-22 11:40

As we move forward, there will be decisions to replicate or not replicate previous behavior in LSL scripts on the maingrid. Many would argue that things that are bugs should not necessarily be carried forward. But, I think we will end up dealing with these on a case by case basis and the community will make the decision what is compatible and what is not.

In any case, when everyone is happy with this patch, and there are at least one "+1" from a core developer and no "-1" from a core developer, we can commit the patch.
melanie (administrator)
2009-02-22 12:00

The warning patch is useful and good. +1
cfk (administrator)
2009-02-22 12:50

I get "unresolved conflicts" with the very first file, that is, ScriptManager.cs at line 288 and cannot move forward with the patch. Can we re-generate the warning patch, please, and I will try again.
DoranZemlja (reporter)
2009-02-22 13:29

did an update and created warning2.patch
cfk (administrator)
2009-02-22 18:44

Commit as r8574
Chilli (reporter)
2009-02-23 04:22
edited on: 2009-02-23 05:12

This warning will fire up on every running script on the region even if it doesn't contain such code. Viewer thinks it comes from current object being scripted. Im not sure if thats what it was intended for? To warn about all running scripts?

It reproduces like this to me:
1) make a prim, Primitive1, and add new script with some l=(l=[])+l+blabla; code inside it

2) compile and see the nice new warning, say on line 30 column 10:
Multiple assignments to 'l' at line 30 column 10; results may differ between LSL and OSSL."

3) make another prim, Primitive2, add a new script to it without any code this time, just the default New Script with its state_entry.

I then see the warning again, even if its not the code inside primitive2:
Multiple assignments to 'l' at line 30 column 11; results may differ between LSL and OSSL."

4) delete all the scripts from all objects in the region , and do step 3) again.

Warning still comes up even if none of the warning-producing scripts are in any rezzed object in the region. Warnings will stop comming up when compiling or adding scripts only after resterting the region.

im running r8579
In addition, my humble opinion:
ok about RTL vs LTR.. fair enough.

But if its not a big job... wouldn't it be a good idea to make l=(l=[])+l+["bar"]; produce l=["foo","bar"]; silently? so sl scripts can work without warning.

WiLLuMPJuH Huisman (reporter)
2009-02-23 10:35
edited on: 2009-02-23 10:45

[csc] Compiling 7 files to '/mnt/sda1/opensim/OpenSim/Data/Tests/bin/Debug/OpenSim.Data.Tests.dll'.
                  [csc] /mnt/sda1/opensim/OpenSim/Data/Tests/BasicAssetTest.cs(41,38): warning CS0414: The private field `OpenSim.Data.Tests.BasicAssetTest.m_log' is assigned but its value is never used
                  [csc] /mnt/sda1/opensim/OpenSim/Data/Tests/BasicEstateTest.cs(43,38): warning

CS0414: The private field `OpenSim.Data.Tests.BasicEstateTest.m_log' is assigned but its value is never used
                  [csc] /mnt/sda1/opensim/OpenSim/Data/Tests/BasicGridTest.cs(42,38): warning CS0414: The private field `OpenSim.Data.Tests.BasicGridTest.m_log' is assigned but its value is never used
                  [csc] /mnt/sda1/opensim/OpenSim/Data/Tests/BasicInventoryTest.cs(41,38): warning CS0414: The private field `OpenSim.Data.Tests.BasicInventoryTest.m_log' is assigned but its value is never used
                  [csc] /mnt/sda1/opensim/OpenSim/Data/Tests/BasicUserTest.cs(45,38): warning CS0414: The private field `OpenSim.Data.Tests.BasicUserTest.m_log' is assigned but its value is never used
                  [csc] Compilation succeeded - 5 warning(s)

Warnings are not fatal.

DoranZemlja (reporter)
2009-02-23 10:39

@ Chilli : I'll look at this tonight. It should be a simple fix.

@ WiLLuMPJuH Huisman :
Someone refactored logging in those modules after I produced the patch. You can look at the SVN log and see who it was. I'll look into it again tonight.
DoranZemlja (reporter)
2009-02-23 13:46

@WiLLuMPJuH Huisman:
I just noticed that NONE of those warnings have anything to do with the patch I produced. I will not look at those warnings tonight. I suggest checking the SVN history to see who last modified those files.
Fly-Man- (developer)
2009-02-23 13:52

@WiLLuMPJuH Huisman:

This is because of the commit that was done about the m_Log changes. Tommil is the one to talk about that one.
DoranZemlja (reporter)
2009-02-23 22:04

multiplewarningfix.patch addresses the problem noted by Chilli
2009-02-24 20:29

ckrinke committed related code in r8604

Fixes Mantis 0003187. Thank you kindly, DoranZemlja for a patch that:
Deals with the multiple warning side affect introduced earlier.

see more at - [^]

- Issue History
Date Modified Username Field Change
2009-02-17 20:02 DoranZemlja New Issue
2009-02-17 20:02 DoranZemlja SVN Revision => 0
2009-02-17 20:02 DoranZemlja Run Mode => Standalone (1 Region) , Standalone (Multiple Regions) , Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)
2009-02-17 20:02 DoranZemlja Physics Engine => BasicPhysics, PhysicsOfSimplicity, ODE, BulletX, PhysX, Other
2009-02-17 20:02 DoranZemlja Environment => Unknown, Mono / Linux32, Mono / Linux64, Mono / Windows, Mono / OSX, .NET / Windows32, .NET / Windows64
2009-02-17 20:02 DoranZemlja Mono Version => None
2009-02-17 20:16 mikem Note Added: 0009539
2009-02-17 20:17 mikem Relationship added related to 0001863
2009-02-17 20:18 mikem Note Edited: 0009539
2009-02-17 21:16 melanie Note Added: 0009540
2009-02-17 21:16 melanie Status new => resolved
2009-02-17 21:16 melanie Resolution open => won't fix
2009-02-17 21:16 melanie Assigned To => melanie
2009-02-17 21:49 DoranZemlja Status resolved => feedback
2009-02-17 21:49 DoranZemlja Resolution won't fix => reopened
2009-02-17 21:49 DoranZemlja Note Added: 0009541
2009-02-18 01:21 WiLLuMPJuH Huisman Note Added: 0009542
2009-02-18 01:37 WiLLuMPJuH Huisman Note Edited: 0009542
2009-02-18 04:53 melanie Note Added: 0009543
2009-02-18 06:26 DoranZemlja Note Added: 0009544
2009-02-18 06:39 DoranZemlja Note Added: 0009545
2009-02-18 07:04 eekee Note Added: 0009546
2009-02-18 08:52 melanie Note Added: 0009550
2009-02-20 19:06 DoranZemlja File Added: error.patch
2009-02-20 19:08 DoranZemlja Note Added: 0009663
2009-02-20 19:08 DoranZemlja Status feedback => patch included
2009-02-20 23:34 dahlia Note Added: 0009664
2009-02-21 00:17 DoranZemlja Note Added: 0009665
2009-02-21 03:20 melanie Note Added: 0009667
2009-02-21 04:44 mikem Note Added: 0009671
2009-02-21 08:31 DoranZemlja Note Added: 0009676
2009-02-21 08:45 DoranZemlja Note Added: 0009677
2009-02-21 10:00 melanie Note Added: 0009685
2009-02-21 10:40 DoranZemlja Note Added: 0009691
2009-02-21 15:46 DoranZemlja File Added: warning.patch
2009-02-21 15:47 DoranZemlja Note Added: 0009701
2009-02-21 18:40 melanie Note Added: 0009705
2009-02-22 07:22 DoranZemlja Note Added: 0009712
2009-02-22 07:30 melanie Note Added: 0009713
2009-02-22 10:26 DoranZemlja Note Added: 0009715
2009-02-22 11:20 melanie Note Added: 0009716
2009-02-22 11:20 melanie Note Edited: 0009716
2009-02-22 11:21 melanie Note Edited: 0009716
2009-02-22 11:30 Gigs Note Added: 0009718
2009-02-22 11:36 DoranZemlja Note Added: 0009719
2009-02-22 11:37 DoranZemlja Note Added: 0009720
2009-02-22 11:40 cfk Note Added: 0009721
2009-02-22 12:00 melanie Note Added: 0009722
2009-02-22 12:50 cfk Note Added: 0009723
2009-02-22 13:29 DoranZemlja Note Added: 0009725
2009-02-22 13:30 DoranZemlja File Added: warning2.patch
2009-02-22 18:44 cfk Status patch included => resolved
2009-02-22 18:44 cfk Resolution reopened => fixed
2009-02-22 18:44 cfk Note Added: 0009728
2009-02-23 04:22 Chilli Status resolved => feedback
2009-02-23 04:22 Chilli Resolution fixed => reopened
2009-02-23 04:22 Chilli Note Added: 0009733
2009-02-23 05:10 Chilli Note Edited: 0009733
2009-02-23 05:12 Chilli Note Edited: 0009733
2009-02-23 10:35 WiLLuMPJuH Huisman Note Added: 0009741
2009-02-23 10:39 DoranZemlja Note Added: 0009742
2009-02-23 10:45 WiLLuMPJuH Huisman Note Edited: 0009741
2009-02-23 13:46 DoranZemlja Note Added: 0009744
2009-02-23 13:52 Fly-Man- Note Added: 0009745
2009-02-23 22:03 DoranZemlja File Added: multiplewarningfix.patch
2009-02-23 22:04 DoranZemlja Note Added: 0009751
2009-02-23 22:04 DoranZemlja Status feedback => patch included
2009-02-24 20:29 user903 Checkin
2009-02-24 20:29 user903 Note Added: 0009764
2009-02-24 20:29 user903 Status patch included => resolved
2009-02-24 20:29 user903 Resolution reopened => fixed
2009-03-11 11:58 chi11ken Status resolved => closed

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker