Talk:Chatbot
Wishes
We could/ should soon add ...
- discover the time of day -- say if World > Force Sun > Region Default would show sunrise, noon, sunset, midnight, or what
- The Chatbot and Hello Avatar examples should continue to learn from each other, e.g., the Chatbot should learn the llSleep part of:
llSetStatus(STATUS_PHYSICS, FALSE); llSleep(0.1);
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
Call for Linux and Windows Volunteers
So far the Windows Second Life client has troubles that don't reproduce anywhere else. So we need people to volunteer to run Linux & Windows in place of the Mac OS X that always works.
Linux demands skill & attention to run well enough to support Second Life. Ppaatt thinks the Linux DVD-R/CD-R known as Knoppix 2007-01-04 and Ubuntu Dapper 6.06.1 do not support Second Life. Ppaatt thinks Ubuntu Feisty 7.04 doesn't support recent 2006 Apple hardware, e.g., ACPI issues. Ppaatt is testing Mac OS X for us. Tim, Huney, Col & Ppaatt are testing Windows for us.
Windows demands skill & attention to run well enough to support Second Life. The Windows installer's claim that you need admin privilege to install appears to be false. Ppaatt has seen copies of "C:\Program Files\SecondLife\" mostly work when dragged to into the "%userProfile%\Downloads\" of other Windows machines.
-- Ppaatt Lynagh 21:54, 22 September 2007 (PDT)
The 2007-09-23 source works in Mac OS X. Counting by eye, Ppaatt says the 2007-09-23 source never cascades more than twenty else-if's.
Does the new 2007-09-23 source work for you in Linux or Windows?
-- Ppaatt Lynagh 14:09, 23 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.
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
(316, 48) : ERROR Syntax Error Second Life 1.18.2 (0) Aug 10 2007 09:34:24 (Second Life Release)
-- 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:
Compile successful, saving... Save complete.
...
"Line 316, Column 0" in world is:
return [llRequestAgentData(llList2Key(ps, 0), llList2Integer(ps, 1))];
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:
$ 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 $
Does that copy work for you?
-- Ppaatt Lynagh 20:12, 13 September 2007 (PDT)
A: Sorry, Ppaatt, no. I get
(316, 48) : ERROR Syntax Error
even when using the source @ aol.com. But as I don't use Linux, I couldn't check integrety.
--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,
-- Ppaatt Lynagh 03:49, 14 September 2007 (PDT)
Ok. First next step:
http://members.aol.com/ppaatt/indexed/secondlife/if-else-if-lsl-20070914a.txt has just 226 source lines in it, rather than 907 of the 13 Sep Chatbot.
Those 226 source lines contain exactly the same 40 "else if" source lines as the 9/13 Chatbot.
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.
Does that compile fail? Here in Mac OS X, that compile succeeds, no worries.
P.S. 11993 bytes is my llGetFreeMemory result, as printed in Mac OS X by that if-else-if-lsl-20070914a.txt script.
-- Ppaatt Lynagh 08:34, 14 September 2007 (PDT)
A: Ppaatt, I get:
(149, 39) : ERROR Syntax Error
Greetz --Huney Jewell 21:43, 14 September 2007 (PDT)
Huney,
Thank you!
The TimZim theory lives: we still now can believe that 40 else-if's are too many for the Windows SecondLife client.
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.
-- 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:
return [llRequestAgentData(llList2Key(ps, 0), llList2Integer(ps, 1))]; 123456789 123456789 123456789 123456789 12345678
Among the 226 lines we saw Windows claim Syntax Error near "Line 149, Column 39":
return [llRot2Euler(llList2Rot(ps, 0))]; 123456789 123456789 123456789 123456789
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.
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?
-- Ppaatt Lynagh 15:12, 15 September 2007 (PDT)
I guess we should next substantially rework the example code.
/7 llGetFreeMemory()
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.
-- Ppaatt Lynagh 15:22, 15 September 2007 (PDT)
The llMessageLinked article is a place where I saw talk of one script calling another.
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:
default
{
state_entry()
{
llOwnerSay((string) llGetFreeMemory());
}
}
-- 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.
Greetz --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.
-- 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.
-- 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.
-- 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.
-- Ppaatt Lynagh 22:51, 18 September 2007 (PDT)
We have a Windows volunteer! I think. Paraphrasing chat off wiki ...
> Syntax error appears in a very strange circumstances.
> It's specified by the compiler as parameter of llList2key(ps,0),
> maybe at line 316 if I remember well.
> I wasn't able to discover the error as parameters seem to be correct.
> I wonder if the error isn't a consequence of some bad characters
> or I don't know bad upper in the source file.
Aye, could be.
"Bug: (316, 48) : ERROR Syntax Error" is the mystery under discussion at http://wiki.secondlife.com/wiki/Talk:Chatbot
> Anyway I could be able to test your updated version and maybe
> send you a screenshot of any remaining problem if any ...
Excellent.
Do you have a guess of how many dozen rounds of this let's-reverse-engineer-Windows work you could endure?
Glancing over http://wiki.secondlife.com/wiki/Talk:Chatbot, I think your next work would be to confirm that you see "(149, 39) : ERROR Syntax Error" when you try, not 907 source lines, but just the 226 source lines of:
http://members.aol.com/ppaatt/indexed/secondlife/if-else-if-lsl-20070914a.txt
Tell me that error is what you see, same as Huney reported, and I can guess what to try next, to discover what the undocumented Windows limit really is.
Tim already above found a patch that makes just the 2007-09-13 version compile in Windows, but we don't yet understand the root cause, so we don't yet know how to make more than one script that runs in Windows, nor can we be sure that compile without error produces correct binary in Windows. If we apply Tim's first guess of a patch, then at most we would fix the trouble for a day, but our Chatbot-lsl-20070913.txt vs. if-else-if-lsl-20070914a.txt sources demo that we'd break again as soon as we copy in the next new feature from Mac OS X, ouch.
-- Ppaatt Lynagh 04:18, 21 September 2007 (PDT)
Hello, I'm Colomben Bailey, newbie script writer unfortunately so I'm not sure I could help you.
I'm running SL viewer on XP as Ppaatt said, and already something confuse me.
I don't understand the difference you make between Mac and XP as AFAIK, scripts are compiled on SL servers not on the viewer.
Sure the script compile when it's saved from Mac??
anyway I trust the TimSim proposal about if/else numbers, not depth because in resultOf() func, if/else depth is one only.
I made a simple test copying resultOf() in a new script. When I save it, I get a syntax error line 129.
If I remove few if test before line 129 and save, syntax error again appear line 129. So, the problem doesn't comes from any real syntax error but certainly from the number of if/else in this func.
do you agree? Col
Col,
Welcome aboard.
I think we're all newbie script writers here together, struggling to help one another.
I agree your theory fits all your data.
I see you guessing that the number of if-else matters. To test that theory, I recommend you try the two sources we saved on the web, specifically:
http://members.aol.com/ppaatt/indexed/secondlife/Chatbot-lsl-20070913.txt
http://members.aol.com/ppaatt/indexed/secondlife/if-else-if-lsl-20070914a.txt
I think you'll see that the number of if-else's is the same in both of these, but the syntax error reported occurs at different spots.
I therefore then don't believe that we're working with an if-else limit. I think we're working with a more complex limit.
Just to drive this point home, any of us could write a simpler script that had lots more of if-else in it. I'll do that next, if no one stops me, just for the sake of educating me the newbie script author on this question.
Thanks again for jumping into help, with your time, your Windows, and the gift of chat.
-- Ppaatt Lynagh 14:12, 22 September 2007 (PDT)
So here now is a more conclusive if-else depth experiment:
http://members.aol.com/ppaatt/indexed/secondlife/Chatbot-lsl-20070913.txt
http://members.aol.com/ppaatt/indexed/secondlife/if-else-if-lsl-20070914a.txt
http://members.aol.com/ppaatt/indexed/secondlife/if-else-deeply-lsl.txt
Do these scripts compile?
Yes Yes Yes is the Mac OS X answer.
No No No might be the Windows answer. If that's the Windows answer, then we're close to having completely reverse engineered an if-else depth limit in Windows. All we do next is twiddle the if-else-deeply-lsl.txt until we know exactly how many else-if's Windows will accept.
No No Yes might be the Windows answer. If that's the Windows answer, then we need to think some more.
The else-if counts for these files are:
$ grep "else if" Chatbot-lsl-20070913.txt | wc -l
47
$ grep "else if" if-else-if-lsl-20070914a.txt | wc -l
40
$ grep "else if" if-else-deeply-lsl.txt | wc -l
49
$
The original Chatbot-lsl-20070913 had the same 40 else-if as if-else-if-lsl-20070914a.txt, but had 7 else-if in other places. The new if-else-deeply-lsl.txt has 49 else-if.
What is the Windows experience of these three scripts?
Most curiously yours,
-- Ppaatt Lynagh 15:39, 22 September 2007 (PDT)
No No No is the Windows answer I get.
In world via Windows, I rezzed an object that had held the three scripts compiled and working, in Mac OS X.
I then recompiled those three scripts in Windows. Every compile failed. Windows reports:
(316, 48) : ERROR : Syntax error (149, 39) : ERROR : Syntax error (100, 15) : ERROR : Syntax error
So the Tim/ Col theory of an undocumented limit on the depth of else-if nesting returns.
Maybe next we'll make time to count the else-if depth in each of those examples. It may be that Second Life rejects the same depth in every example, or maybe life is not so simple.
Maybe next we'll twiddle the if-else-deeply-lsl.txt script to demo counting else-if depth just to 24 rather than to 49. Then we could post that result as a concise new article of this wiki, documenting this Windows limit. Then we can commit to designing all future versions of the Chatbot to fit this undocumented Windows limit, for the sake of being compiled on any platform.
-- Ppaatt Lynagh 22:42, 22 September 2007 (PDT)
I've rolled much of the talk of how much else-if depth is too much into LSL_Errors.
I think we need to write a separate article, among the with a titled like Too_Many_Else_If, to explore how the limit is sometimes 23 or 24 or 26, not always 23. Congrats again to Tim & Col for the correct intuition that if-else depth was the issue, although not a fixed limit.
I remember Wikipedia netiquette says to archive chats like this, never delete them. I guess our netiquette here is different. I think here in Wiki.secondlife.com we're supposed to edit out concluded chats like these. We don't really delete the chat - it still appears, but only well buried in the long ago parts of the History tab.
Since the limit is fuzzy, I'll try tweaking the Chatbot to live within a smaller limit, like a max of 20 else-if. Since I've got Windows running now, I can test in Windows as well as Mac OS X before I release the new code. Mind you, I still have no way to test Linux.
Thanks again to all of us for stepping us this far forward in our newbie understanding.
-- Ppaatt Lynagh 07:28, 23 September 2007 (PDT)
Ouch that was slow & painful. Anybody still here with me?
Does the new 2007-09-23 source work for you in Linux or Windows?
The 2007-09-23 source works in Mac OS X. Counting by eye, Ppaatt says the 2007-09-23 source never cascades more than twenty else-if's.
-- Ppaatt Lynagh 14:09, 23 September 2007 (PDT)
Hi Ppaatt, I'm still here and I try to get more informations about the problem. Until now, nothing!
I agree with your last comments. I tried your scripts and got the same result.
But what do you mean by last 2007-09-23 script? is it the one we can get from the article?
I'm still wondering what the platform means here! does the compilation now takes place on the viewer side now??
Regards, -- User:Colomben_Bailey
> I agree with your last comments. I tried your scripts and got the same result.
Thank you for confirming.
> But what do you mean by last 2007-09-23 script? is it the one we can get from the article?
Yes exactly, please try that script in Windows, the version that begins with the datestamp "// 2007-09-23 ...".
I see that script working in Mac OS X. Does it work in Windows also? I argue that it should by the data at LSL_Errors, but I do not yet know, I have not yet tried Windows. Personally I have Windows available sometimes, not always.
> I'm still wondering what the platform means here!
Sorry I do not know, I wonder likewise.
> does the compilation now takes place on the viewer side now??
Sorry I do not know. Certainly the results vary by operating system, e.g., Mac OS X vs. Windows.
-- Ppaatt Lynagh 14:24, 25 September 2007 (PDT)
Mac OS X still likes 2007-09-23, Windows still chokes.
"(326, 42) : ERROR : Syntax error" refuses to compile the 19 cascaded else-if's, in Windows.
But the refactoring of 2007-09-23 lets us divide those 19 cascaded else-if's into cascades of 10 and 9 else-if's, which works, even in Windows.
Consequently, I'll now volunteer me to delete exactly one "else" word from the article, and then test that result in Windows to confirm that what compiles also in fact mostly works. Please standby ...
-- Ppaatt Lynagh 18:51, 25 September 2007 (PDT)