Difference between revisions of "Talk:Chatbot"

From Second Life Wiki
Jump to navigation Jump to search
m (In pursuit of me being able to see this perhaps Windows-only Syntax Error ...)
m (→‎News: - LSL_Protocol/ListMessage has code now - likely the seed of what will replace the first draft of the Chatbot)
 
(24 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Call for Volunteers ==
You can help by adding bugs, fixing bugs, and adding comments here to tell us why and how you are or are not working with your own Chatbot.
You can help by running the Chatbot in Linux, even if you have been running only Mac OS X or Windows on your computer.
See: http://wiki.secondlife.com/wiki/LSL_Write_Once_Debug_Everywhere#Running_Linux
== News ==
The [[LSL_Protocol/ListMessage]] article now has a little code in an example - likely the seed of what will replace the first draft of the Chatbot.
== Wishes ==
== Wishes ==


We could/ should soon add ...
We could/ should soon add ...


* llGetFreeMemory in the demo
* rewrite to use the [[LSL_Protocol/ListMessage]] to divide the work of interpreting LSL among indefinitely many scripts via [[llMessageLinked]] and [[link_message]]


* discover the time of day -- say if World > Force Sun > Region Default would show sunrise, noon, sunset, midnight, or what
We could/ should soon add ...


* move to owner and stop moving
* say if [[llGetSunDirection]] changes or not when World > Force Sun > Region Default shows sunrise, noon, sunset, midnight, or what -- likely it doesn't, the object doesn't know what its owning or creating avatar sees
 
We could/ should soon add ...
 
* move to owner and stop moving.


* parsing of prefix monadic + - arithmetic operators, for scalar and vectors and rotations
* parsing of prefix monadic + - arithmetic operators, for scalar and vectors and rotations
Line 13: Line 29:
* parsing of infix dyadic + - * / % arithmetic operators with precedence, on pairs of values of the same type, on vector/ rotation pairs, on rotation/ vector pairs
* parsing of infix dyadic + - * / % arithmetic operators with precedence, on pairs of values of the same type, on vector/ rotation pairs, on rotation/ vector pairs


The [[Chatbot]] and [[Hello Avatar]] examples should continue to learn from each other, e.g., the Chatbot should learn the llSleep part of:
* forever periodically resynch or somehow merge the [[Chatbot]] and [[Hello Avatar]] examples
 
<pre>
llSetStatus(STATUS_PHYSICS, FALSE); llSleep(0.1);
</pre>


== Bugs ==
== Bugs ==
Line 48: Line 60:


-- [[User:Ppaatt Lynagh|Ppaatt Lynagh]] 07:42, 14 September 2007 (PDT)
-- [[User:Ppaatt Lynagh|Ppaatt Lynagh]] 07:42, 14 September 2007 (PDT)
== Bugs That May Have Been Fixed ==


=== Bug: (316, 48) : ERROR Syntax Error ===
=== Bug: (316, 48) : ERROR Syntax Error ===


<pre>(316, 48) : ERROR Syntax Error
The thousand lines of Chatbot script is script enough to confuse some compilers.
Second Life 1.18.2 (0) Aug 10 2007 09:34:24 (Second Life Release)</pre>
 
-- kindly reported by e-mail
 
I suspect we're facing some difficulty in perfecting the accuracy of the copy/ paste of a thousand lines of script.
 
The Second Life client app that works for me says it was released to me just ~3 minutes later:
Help > About Second Life is "Second Life 1.18.2 (0) Aug 10 2007 09:37:04 (Second Life Release)"
 
Here I see:
 
<pre>Compile successful, saving...
Save complete.</pre>
 
...
 
"Line 316, Column 0" in world is:
<pre>return [llRequestAgentData(llList2Key(ps, 0), llList2Integer(ps, 1))];</pre>
 
Hard to understand how that syntax can be wrong while the previous syntax is correct.
 
...
 
I've stored a copy of this script as Chatbot-lsl-20070913.txt at
http://members.aol.com/ppaatt/indexed/secondlife/
 
My integrity checks on the script here are:
 
<pre>$ ls -l Chatbot-lsl.txt
-rw-r--r--@ 1 pat  staff  22876 13 Sep 20:02 Chatbot-lsl.txt
$ openssl md5 Chatbot-lsl.txt
MD5(Chatbot-lsl.txt)= 9373258278a20329c7ba39353454059c
$ </pre>
 
Does that copy work for you?
 
-- [[User:Ppaatt Lynagh|Ppaatt Lynagh]] 20:12, 13 September 2007 (PDT)
 
A: Sorry, Ppaatt, no. I get
 
<code>(316, 48) : ERROR Syntax Error </code>
 
even when using the source @ aol.com. But as I don't use Linux, I couldn't check integrety.
 
--[[User:Huney Jewell|Huney Jewell]] 21:32, 13 September 2007 (PDT)
 
_____________________________________________________________________________________
 
Ppaatt, thanks for the response
 
Your volunteer status is noted and appeciated.
 
I tried commenting out blocks of code before/after but still got the same error.
 
I then tried breaking that huge if..else..else into three if statements. That compiled, so the issue is the number of else's in an if statement.
 
Regards
 
TimZim Teatime
 
_____________________________________________________________________________________
 
Ah fun.
 
1.
 
Me, I'm using Mac OS X. Yes please let's chase this theory that the results vary by client platform: Apple Mac OS X, Linux, Windows, whatever.
 
I'll return here with a short example that contains nothing but the resultOf routine called by default.state_entry. Then someone for whom http://members.aol.com/ppaatt/indexed/secondlife/Chatbot-lsl-20070913.txt fails can try that example, and prove that such a short example still fails.
 
I'll also provide an almost identical short example that differs only by breaking the huge if..else..else into three if statements. Then someone can prove that some platforms fail the huge if..else..else and accept the broken if..else..else.
 
Once we have a simple good/bad test case, then we can run down what the limit is exactly, in terms of a count of else if branches allowed. Then we can write a wiki article here to announce to the world this limit that we must live by.
 
Or ... we can volunteer you to do that work of defining this experiment in detail for us, as well as the work of conducting the experiment. :-)
 
2.
 
I'll work on getting Linux or Windows to boot here. Are any of you who see failure already using Linux by chance? That would be easiest, e.g., kernel.org Knoppix Linux I can boot from DVD-R or CD-R.
 
Getting Windows going will be harder, but eventually possible, I think. I can borrow a license from work and deploy Windows somewhere.
 
3.
 
llGetFreeMemory might be relevant in world.
 
I'll return here with a quote of what my llGetFreeMemory is.
 
4.
 
Thanks again and again in advance,


-- [[User:Ppaatt Lynagh|Ppaatt Lynagh]] 03:49, 14 September 2007 (PDT)
The [[LSL Write Once Debug Everywhere]] article explains how you can develop LSL scripts that run well and compile without error in many places.


Ok. First next step:
The [[LSL Errors]] article explains the astonishing 2007-08 Windows compiler limit of about a dozen cascaded else-if's (astonishing when contrasted to the Mac limit of about five hundred).


http://members.aol.com/ppaatt/indexed/secondlife/if-else-if-lsl-20070914a.txt
The talk archive at http://wiki.secondlife.com/w/index.php?title=Talk:Chatbot&oldid=32867#Bug:_.28316.2C_48.29_:_ERROR_Syntax_Error
has just 226 source lines in it, rather than 907 of the 13 Sep Chatbot.
tells the story of how Col, Huney, Ppaatt and Tim reverse-engineered, documented, and worked around the limits on cascading else-if's.  


Those 226 source lines contain exactly the same 40 "else if" source lines as the 9/13 Chatbot.
-- [[User:Ppaatt Lynagh|Ppaatt Lynagh]] 06:14, 26 September 2007 (PDT)


By the TimZim theory of an if-else-if depth limit in Second Life for Windows ... that script should fail to compile, with a syntax error.
== Rethink ==


Does that compile fail? Here in Mac OS X, that compile succeeds, no worries.
I have by now thought thru a new design for ducking our ill-defined not-quite-cross-platform-reproducible script resource limits by dividing the work out via llMessageLinked.


P.S. 11993 bytes is my llGetFreeMemory result, as printed in Mac OS X by that if-else-if-lsl-20070914a.txt script.
Sorry as yet I'm thinking in the deeply geeky slang of compiler folk. Out in that world, my thinking runs as follows.


-- [[User:Ppaatt Lynagh|Ppaatt Lynagh]] 08:34, 14 September 2007 (PDT)
http://members.aol.com/ppaatt/#%5B%5BReverse%20Polish%20LSL%5D%5D is my definition of Reverse Polish LSL. I figure we want to chat ordinary LSL onto a channel, then see (forward) Polish chatted on a channel. In translating from ordinary LSL, we'd chat the depth-first Polish first, i.e., the leftmost ( ... ) found, with just values as parameters. We'd then see the result chatted on a channel, which will let us form the next expression out.
----
A: Ppaatt, I get:


<code>(149, 39) : ERROR Syntax Error </code>
I plan to head that way here as soon as I get some more time slices free to work this. That way will let us divide the else-if's arbitrarily into indefinitely many functions.
<br/>
Greetz --[[User:Huney Jewell|Huney Jewell]] 21:43, 14 September 2007 (PDT)


----
I figure we can define monadic == to mean evaluate a name.
Huney,


Thank you!
I figure we can use simply-quoted URL-encoding to pass strings around.


The TimZim theory lives: we still now can believe that 40 else-if's are too many for the Windows SecondLife client.
I figure we want to distinguish no result, void result, non-list non-void result, possibly-empty list result. I figure we count the "no results" til we have enough, to know when no one listening can make sense of the Polish LSL that was chatted.
 
Next I will look to see if it is the same sourceline involved in both failures so far.
 
If yes, then I will delete just the else there, and ask you Windows folk to report if that minimal change defeats the error.
 
-- [[User:Ppaatt Lynagh|Ppaatt Lynagh]] 10:39, 15 September 2007 (PDT)
 
Ouch our theory of count the else-if's dies!
 
Among the 907 lines we saw Windows claim Syntax Error near "Line 316, Column 48" in world:
<pre>        return [llRequestAgentData(llList2Key(ps, 0), llList2Integer(ps, 1))];
123456789 123456789 123456789 123456789 12345678</pre>
 
Among the 226 lines we saw Windows claim Syntax Error near "Line 149, Column 39":
<pre>
        return [llRot2Euler(llList2Rot(ps, 0))];
123456789 123456789 123456789 123456789</pre>
 
I wish we had seen the same source line involved in both failures, rather than two different source lines. If we had seen the same source line twice, then I could believe the persuasive TimZim theory that we're reverse-engineering a limit on if-else-if branches.
 
As is, we have to abandon that first theory, and guess again.


-- [[User:Ppaatt Lynagh|Ppaatt Lynagh]]
-- [[User:Ppaatt Lynagh|Ppaatt Lynagh]]
Huney, TimZim, ...
Feeling compulsive?
Anyone with a Windows client could reconfirm/ revise/ deny the key data that drives our conclusions here ...
We're claiming a difference exists between:
http://members.aol.com/ppaatt/indexed/secondlife/Chatbot-lsl-20070913.txt
http://members.aol.com/ppaatt/indexed/secondlife/if-else-if-lsl-20070914a.txt
We claim those two scripts share the same line count and syntaxed of if-else-if, yet somehow the Windows client rejects one sourceline in the one script and another sourceline, several lines away, in the other script.
That's exactly right now?
-- [[User:Ppaatt Lynagh|Ppaatt Lynagh]] 15:12, 15 September 2007 (PDT)
I guess we should next substantially rework the example code.
<pre>/7 llGetFreeMemory()</pre> reports a small number like 3566 here, even on the Mac client.
We should find we can add enough more code to blow out the Mac client, similarly to the Windows client.
We should find we can teach the example to chat to itself, so that people can compile the example as one script, or follow simple instructions for dividing the example into more than one script, to duck limits on how much we say in the one script by dividing out the work of which script interprets what.
For example, we could work to move the valueOf and resultOf routines into another script.
I'm ok on the concept here, but weak on the LSL as yet. I've seen references to LSL being used to let one script talk to another. I'll have to go chase those before I can contribute such a restructuring here myself.
-- [[User:Ppaatt Lynagh|Ppaatt Lynagh]] 15:22, 15 September 2007 (PDT)
The [[llMessageLinked]] article is a place where I saw talk of one script calling another.
-- [[User:Ppaatt Lynagh|Ppaatt Lynagh]]
Me, for one, I remain interested in discovering exactly what the Windows resource limit here that is so much tighter than the Mac limit.
16172 is the report I see in Mac every time I drag another copy of the following script into an object:
<pre>default
{
    state_entry()
    {
        llOwnerSay((string) llGetFreeMemory());
    }
}</pre>
-- [[User:Ppaatt Lynagh|Ppaatt Lynagh]] 15:22, 15 September 2007 (PDT)
----
A: Ppaatt, same result with Windows client: 16172. As far as I know, script memory is limited to 16384 bytes. This is a limit per script, not per object. Thus you can overcome the limit by splitting up a script and simulate subroutine calls by use of link messages.
<br/>
Greetz --[[User:Huney Jewell|Huney Jewell]] 23:47, 15 September 2007 (PDT)
----
Huney,
Thank you for this further work.
That 16384 limit was astonishing news to me, yes thank you. Newbie me, I had not correctly understood the mess that was the [[llGetFreeMemory]] article. Per your hint I immediately wrote a new example for that article - my new example shows the heap size actually changing over time. I also rewrote the entire article, now that I see what's really happening. I'd welcome your review of my rewrite of course.
-- [[User:Ppaatt Lynagh|Ppaatt Lynagh]] 06:54, 16 September 2007 (PDT)
I just now linked the [[llGetFreeMemory]] and [[LSL_Errors]] articles together.
Text at the [[LSL_Errors]] article, as well as the example posted before mine into the [[llGetFreeMemory]] article, agree with Huney that the limit is 16384 = 16.384 K = 16 Ki. Looks like our wiki isn't too careful about distinguishing when K = 1000 and when K = 1024 = Ki, as yet.
The [[LSL_Errors]] article says the memory limited divides into byte code, stack, and heap. Not just stack and heap.
-- [[User:Ppaatt Lynagh|Ppaatt Lynagh]] 07:13, 16 September 2007 (PDT)
Back on the Mac client I tried including a second copy of the resultOf routine in the script. I named it resultOf2, I didn't bother to call it. Even so, I saw "Script run-time error" "Stack-Heap Collision". Thus it feels like the new source does eat up additional byte code space. 
Still no Syntax Error on the Mac.
-- [[User:Ppaatt Lynagh|Ppaatt Lynagh]] 07:13, 16 September 2007 (PDT)
In pursuit of me being able to see this perhaps Windows-only Syntax Error ...
I have Linux running now, as well as Mac OS X.
Regrettably, the alpha Linux SecondLife client doesn't just plain work for my boot of the Knoppix Linux DVD-R. I die with windowing errors even before I get a chance to try to login.
The 2006-11 RTM Vista Windows plus the Second Life client is on its way here for test, via the Boot Camp beta for Mac OS X that lets me choose Windows or Mac OS X for each boot. In that thread we're only waiting for more time slices from me.
-- [[User:Ppaatt Lynagh|Ppaatt Lynagh]] 22:51, 18 September 2007 (PDT)
----

Latest revision as of 20:13, 14 October 2007

Call for Volunteers

You can help by adding bugs, fixing bugs, and adding comments here to tell us why and how you are or are not working with your own Chatbot.

You can help by running the Chatbot in Linux, even if you have been running only Mac OS X or Windows on your computer.

See: http://wiki.secondlife.com/wiki/LSL_Write_Once_Debug_Everywhere#Running_Linux

News

The LSL_Protocol/ListMessage article now has a little code in an example - likely the seed of what will replace the first draft of the Chatbot.

Wishes

We could/ should soon add ...

We could/ should soon add ...

  • say if llGetSunDirection changes or not when World > Force Sun > Region Default shows sunrise, noon, sunset, midnight, or what -- likely it doesn't, the object doesn't know what its owning or creating avatar sees

We could/ should soon add ...

  • move to owner and stop moving.
  • parsing of prefix monadic + - arithmetic operators, for scalar and vectors and rotations
  • parsing of infix dyadic + - * / % arithmetic operators with precedence, on pairs of values of the same type, on vector/ rotation pairs, on rotation/ vector pairs

Bugs

This Chatbot script works reasonably well for some of us ... how about you? If not, why not?

Bug: Channel number omitted, comma included, in echo of list value

STEPS TO REPRODUCE: 

/7 [a, b, c] // a list value

EXPECTED RESULTS: 

/7 [a, b, c] // a list value
[a, b, c]

ACTUAL RESULTS: 

// [a, b, c] // a list value
, [a, b, c]

See? The channel number 7 is missing from the echo, broken by design.

See? A spurious string ", " of comma and blank appears before the expected result, who knows why.

Another example that produces the spurious ", " is: 

/7 [llGetFreeMemory(), llGetFreeMemory(), llGetFreeMemory()]

Thus likely this bug is with output of type list, not with input of type list.

-- Ppaatt Lynagh 07:42, 14 September 2007 (PDT)

Bugs That May Have Been Fixed

Bug: (316, 48) : ERROR Syntax Error

The thousand lines of Chatbot script is script enough to confuse some compilers.

The LSL Write Once Debug Everywhere article explains how you can develop LSL scripts that run well and compile without error in many places.

The LSL Errors article explains the astonishing 2007-08 Windows compiler limit of about a dozen cascaded else-if's (astonishing when contrasted to the Mac limit of about five hundred).

The talk archive at http://wiki.secondlife.com/w/index.php?title=Talk:Chatbot&oldid=32867#Bug:_.28316.2C_48.29_:_ERROR_Syntax_Error tells the story of how Col, Huney, Ppaatt and Tim reverse-engineered, documented, and worked around the limits on cascading else-if's.

-- Ppaatt Lynagh 06:14, 26 September 2007 (PDT)

Rethink

I have by now thought thru a new design for ducking our ill-defined not-quite-cross-platform-reproducible script resource limits by dividing the work out via llMessageLinked.

Sorry as yet I'm thinking in the deeply geeky slang of compiler folk. Out in that world, my thinking runs as follows.

http://members.aol.com/ppaatt/#%5B%5BReverse%20Polish%20LSL%5D%5D is my definition of Reverse Polish LSL. I figure we want to chat ordinary LSL onto a channel, then see (forward) Polish chatted on a channel. In translating from ordinary LSL, we'd chat the depth-first Polish first, i.e., the leftmost ( ... ) found, with just values as parameters. We'd then see the result chatted on a channel, which will let us form the next expression out.

I plan to head that way here as soon as I get some more time slices free to work this. That way will let us divide the else-if's arbitrarily into indefinitely many functions.

I figure we can define monadic == to mean evaluate a name.

I figure we can use simply-quoted URL-encoding to pass strings around.

I figure we want to distinguish no result, void result, non-list non-void result, possibly-empty list result. I figure we count the "no results" til we have enough, to know when no one listening can make sense of the Polish LSL that was chatted.

-- Ppaatt Lynagh

Retrieved from "https://wiki.secondlife.com/w/index.php?title=Talk:Chatbot&oldid=35674"