Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005006opensim[REGION] Scripting Enginepublic2010-08-31 06:202013-08-13 17:22
Reporterplayer 
Assigned To 
PrioritynormalSeveritytweakReproducibilityalways
Statuspatch includedResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0005006: LSL implementation does not allow parenthesis assignments
DescriptionThis bug is closely related to 0003874
The LSL implementation in version 0.7.0.1 does not compile assignments like the following:

(lvalue = val);

but these are actually accepted by the LL's LSL and the code generated by LSLPlus uses that kind of statements a lot.

Here is a patch that fixes the problem for me.
Additional InformationWith the current implementation, the mcs compiler replies: CS0201: Only assignment, call, increment, decrement, and new object expressions can be used as a statement.

The mono version is 2.6.4 64-bit distributed with Fedora 13.
TagsNo tags attached.
Git Revision or version number0
Run ModeStandalone (1 Region)
Physics EngineBasicPhysics
Script Engine
EnvironmentMono / Linux64
Mono VersionOther
Viewer
Attached Filespatch file icon lsl-parenthesis-statements-allowed.patch [^] (1,091 bytes) 2010-08-31 06:20 [Show Content]

- Relationships
has duplicate 0005422new (i = 1); fails to compile 

-  Notes
(0016700)
melanie (administrator)
2010-09-01 10:43

This is, I presume, to facilitate listvar = (listvar = []) + listvar + [newval]

The above is the "spacesave hack" for LSO and isn't supported in OpenSim. Even if the compilation succeeds, such expressions' side effects differ between LSL and OSSL.

It's open for discussion if we should allow this to be compiled. Leaving things as is would mean that possibly problematic code would fail and needs to be revised. Committing this patch would allow this code to compile, but it would work differenly, because LSL collates right to left, and OSSL collates left to right.

Comments?
(0016704)
Marck (reporter)
2010-09-01 12:07

What I gather from the descriptions in this report and that in 0003874, the main intention is not to make that "spacesave hack" work but rather to allow the use of the LSL Plus Eclipse Plugin for scripting with OpenSimulator. LSL Plus is an IDE for LSL which generates code that extensively uses those lone expressions. http://wiki.secondlife.com/wiki/LSL-Plus [^]

I would say that this is a good reason for allowing such code to compile. To address the concern of different collating I suggest the introduction of a configuration parameter which allows the activation of this patch. Its default setting should be such that the current behaviour is retained. I would assume that people who are using the LSL Plus IDE and enable this patch are aware of the possible consequences.
(0016705)
melanie (administrator)
2010-09-01 12:11

Users od LSL Plus would then create code that doesn't run as intended. Parentheticals like these are not needed except for their side effects, and these side effects differ between LSL and OSSL. It's even money for any given script using them that it won't work as intended, malfunction, crash or fail in nonobvious ways. And the user would not even be alerted to it. The proper solution here is making LSL Plus OSSL aware, so that such expressions are not created.
(0016706)
Marck (reporter)
2010-09-01 12:19

From 0003874:

This is an example for code that is generated from LSL Plus:

for ((i = 0); (i < 10); (++i)) {
  llSay(0, (string) i);
}

This is perfectly valid code which is semantically equivalent to:

for (i = 0; i < 10; ++i) {
  llSay(0, (string) i);
}

The former is rejected with an error:

Error compiling script: Line (7,14): Error CS0201: Only assignment, call, increment, decrement, and new object expressions can be used as a statement

The intention of this patch, as far as I understand it, is to allow code like that in the first example. Again, this is _not_ about constructs like the "spacesave hack".
(0016708)
melanie (administrator)
2010-09-01 12:51

Oh, I see. So LSLPlus doesn't create those as subassignments, but rather generates extraneous parentheses.

It should not do that, it's evil. However, yes, the code would run without errors with this patch.

Any other stakeholders care to comment?
(0016709)
player (reporter)
2010-09-01 13:42

Melanie I see your point and the patch I submitted probably isn't the best way to fix this issue, so I'll have to think of some other way to do it.
But I disagree with the opinion that LSLPlus should fix anything, because the code it produces runs fine in LSL. It doesn't produce any overhead nor higher memory usage so I can't see any reason why it should be considered "evil".
In my moot opinion I think that OSSL should try to be the most LSL compatible as possible, if not 100%. And it means that it should reproduce every behavior and misbehavior of LSL.
(0016712)
melanie (administrator)
2010-09-01 14:18

I disagree. We aim to not reproduce the bugs. parentheses around the initializer and increment of a for are not part of the syntax. SL accepts them, probably doe to a sloppily done parser. But should we duplicate the sloppiness? LSLPlus should not generate these parentheses.
(0016713)
Marck (reporter)
2010-09-01 14:34
edited on: 2010-09-01 14:35

I disagree. We should not aim to stick with an insanely strict parser that rejects perfectly valid code which just has some "syntactic sugar" but is otherwise semantically sane. A parser should not complain about extraneous parentheses. It should not do that, it's evil.

(0016714)
player (reporter)
2010-09-01 15:00
edited on: 2010-09-01 15:15

Many times I submitted bug reports to jira because of the LSL syntax weirdness. Sometimes they replied «we can't fix this now, because it would break many existing scripts», some other times they said «LSL is not C» (yes, really, like when I reported the execution of an int f() in (FALSE && f()) and (f() && FALSE) ) but the conclusion was always the same: they wouldn't fix it.

So why not definitively take such sloppinesses as part of the LSL? As far as I know there is no such "official formal LSL language definition", so LL's implementation is the only thing that defines the LSL somehow. I know, it sucks, but that's the way things are going.

(0016715)
melanie (administrator)
2010-09-01 15:49

i'm not sure if i agree with this reasoning. If LL doesn't fox bugs, that doesn't mean we can't.
Anyway, it would be ok if those were accepted within a for() statement, etc, the issue i see is with parentheticals within arithmetic evaluation (spacesave hack). The spacesave hackk should really generate errors.

Anyway it seems all are in favor, so....
(0016716)
melanie (administrator)
2010-09-01 15:50

let's get it in...
(0016717)
jhurliman (manager)
2010-09-01 15:57
edited on: 2010-09-01 17:51

Speaking of questionable reasoning...

The spacesave hack uses assignments in parentheses
The spacesave hack should generate errors in OpenSim
Therefore, assignments in parentheses should generate errors

Hard to argue with that logic.

(0016718)
melanie (administrator)
2010-09-01 15:58

assignments within parentheses are generating errors. the spacesave hack uses assignments in parentheses
(0018804)
Ewe Loon (reporter)
2011-07-09 14:26

I deleted relationship to 5576 because \
one id failure to compile
the other is execution order
(0021464)
kevinbuckley70 (reporter)
2012-05-18 10:33

Trying to use Eclipse/LSL Plus with Opensim 0.7.3.1 still exhibits this problem for me. Was this fixed (as seems to be indicated by Justin in the issue history), or not?
(0021465)
justincc (administrator)
2012-05-18 16:17

No, I change back to patch included so it would be flagged better but I've never had a chance to think about it myself and it became old enough to fall off my radar.
(0021467)
kevinbuckley70 (reporter)
2012-05-19 00:39

Opensim allows for much more complex scripting than lsl which is good. But that means having better tools becomes necessary. So something like Eclipse with subversion, and the ability to integrate your library of common functions as you can with lsl plus (as well as having live syntax checking) is really helpful. But possibly not worth the overhead of having to run with a patched installation. Is it likely that this will get incorporated into the main release anytime soon (or ever)?
(0021476)
justincc (administrator)
2012-05-21 14:33

Will try and think about this soon.
(0024272)
dslake (manager)
2013-08-13 17:22

This problem seems to affect any statement with parenthesis around it such as the following example which gives the same compile error. It also appears to happen in newer versions of Mono because Doug Maxwell from ARL reports that it works on his MOSES grid with OpenSim 0.7.4 but it does not work on MOSES DSG with Mono 2.10.8.1 and OpenSim master.

default
{
    state_entry()
    {
        (llSay(0, "HelloWorld"));
    }
}

- Issue History
Date Modified Username Field Change
2010-08-31 06:20 player New Issue
2010-08-31 06:20 player File Added: lsl-parenthesis-statements-allowed.patch
2010-08-31 06:20 player Git Revision => 0
2010-08-31 06:20 player SVN Revision => 0
2010-08-31 06:20 player Run Mode => Standalone (1 Region)
2010-08-31 06:20 player Physics Engine => BasicPhysics
2010-08-31 06:20 player Environment => Mono / Linux64
2010-08-31 06:20 player Mono Version => Other
2010-09-01 04:54 Marck Status new => patch included
2010-09-01 10:43 melanie Note Added: 0016700
2010-09-01 12:07 Marck Note Added: 0016704
2010-09-01 12:11 melanie Note Added: 0016705
2010-09-01 12:19 Marck Note Added: 0016706
2010-09-01 12:51 melanie Note Added: 0016708
2010-09-01 13:42 player Note Added: 0016709
2010-09-01 14:18 melanie Note Added: 0016712
2010-09-01 14:34 Marck Note Added: 0016713
2010-09-01 14:35 Marck Note Edited: 0016713
2010-09-01 15:00 player Note Added: 0016714
2010-09-01 15:15 player Note Edited: 0016714
2010-09-01 15:49 melanie Note Added: 0016715
2010-09-01 15:50 melanie Note Added: 0016716
2010-09-01 15:50 melanie Status patch included => patch ready
2010-09-01 15:57 jhurliman Note Added: 0016717
2010-09-01 15:58 melanie Note Added: 0016718
2010-09-01 16:00 jhurliman Note Edited: 0016717
2010-09-01 17:51 jhurliman Note Edited: 0016717
2011-03-28 02:52 Marck Relationship added has duplicate 0005422
2011-07-09 07:14 makopoppo Relationship added related to 0005576
2011-07-09 14:26 Ewe Loon Relationship deleted related to 0005576
2011-07-09 14:26 Ewe Loon Note Added: 0018804
2011-10-21 19:15 justincc Status patch ready => patch included
2012-05-18 10:33 kevinbuckley70 Note Added: 0021464
2012-05-18 16:17 justincc Note Added: 0021465
2012-05-19 00:39 kevinbuckley70 Note Added: 0021467
2012-05-21 14:33 justincc Note Added: 0021476
2013-08-13 17:22 dslake Note Added: 0024272


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker