I’ve put in several hours on this and can’t get anything to work.

Can anyone advise me on how to preview multi-sentence input to get some stats on it before proceeding with regular analysis?

Specifically,  my chatbot-patient, in a patient-exam situation,  typically faces user input that is very structured.  Almost all of it is either a list of lab values,  or { response . } { transition . } { question .}  I’m paraphrasing—there is one, two, or three sentences, and the ones that occur always occur in that order.

It would help me,  before analyzing the input any further, to determine which of those 9 cases I’m facing.  I can tell, looking at a single sentence,  which one it is.

I can even read through the entire input, using (%more) and nextInput(), etc. to determine what I have.  I can put the pattern I’m facing into a variable.  I can capture all of the input into a $tmp string like “fine. let’s look at your eyes. When was your last eye exam?”.

What I cannot figure out is the probably very simple thing of how, at that point,  to fail the topic that did the analysis of the multi-sentence structure and have the rest of simpletopic.top act as if the 1-4 sentences had just arrived,  except I also know now what is coming down the pike while I’m analyzing the first sentence.

I’ve tried all the combinations I can think of, like ^input($tmp)  ^fail(topic) ,  or ^disable(topic thisone)  (re-enabling it in the preprocessing step in simplecontrol.top),  or adding “priority” to the analysis topic, and what I get is either

(a)  the analysis topic (with pattern (*) ) is ignored entirely (despite repeat noerase) or
(b)  the analysis topic is processed,  and failed, but then no other topic picks up the ball.

Does that make sense?

In the NORMAL course of events, Chatscript processes sentences one at a time, in order, irrevocably. You can’t go back and say “OK. I’ve seen it all. Now do it again for real”. That is the NORMAL course of events.

You could cheat, of course.  I’d have to see your actual script (+ test input).

Let’s assume you have a control topic you call which does this preanalysis of sentences and stores them concatenated onto $$tmp.  And it’s called 1st thing from your main control topic. And the first thing this topic does is see if it shouldnt do anything… eg

u: ($$scanning) ^fail(TOPIC) —we completed all analysis
after which is analyses the sentence, adds it to $$tmp, and when done, does ^fail(SENTENCE).
On the LAST sentence (!%more) instead of failing sentence, it
a) $$scanning = 1
b) ^input ($$tmp)
c) ^FAIL(SENTENCE)—- NOT FAIL(TOPIC)

then thereafter the main input should be a copy of all of your previous sentences, the analysis topic does nothing, and you have set whatever analysis information you wanted.
Is this what you have?

OK, I got it working.  Thank you.

The attached file “prescantops.zip” contains a “simple” simplecontrol.top and simpletopic.top, as stripped down as I can get them, and annotated,  to illustrate a fully-working verision of prescanning each volley of user input to count the sentences and know what’s coming before actually processing it normally.

The count and full stream are available in user variables and printed out at the end.
I tested it with “Hello” followed by “What is your name?”  or
“What is your name?  The sky is blue.  I like blue.”

No promises made of fitness for any particular purpose aside from being an example of Chatscript.

Thank you again BRUCE for all the help!

Enjoy

Wade

Oh, one more thing.  I found out that ^print( stuff ) is counted as successful output by the system,  which defeats it’s easy use as a debugging tool right onto the screen.

How do I print debugging into to the screen but NOT have them count as if some rule had succeeded?    Print to the log and echo it or something?

Wade

Yes, you can use ^LOG( ) —you might have to do :echo all   first to echo log to screen.

Also, your ~countem topic might as well be declared system (which includes noerase and nostay). Then there is no need for poptopic(~countem)  elsewhere.  Also there are no keywords needed for that topic ($code=main *) is meaningless as a topic keyword list.

And in that topic $onestring lasts forever, and would make more sense as $$onestring to be transient, except you don’t even need that because whereever you use $onestring you can just use ‘_0 .  Similarly $tmp would be better as $$tmp.

Nor should the angelabot have “^addtopic(~countem)” in it, because you explicitly call it from control so starting with it has no meaning.

You describe # count how many incoming “sentences” were processed
  #  note:  ” hello, how are you” is one incoming sentence but TWO once processed
  #      we are counting it as one unprocessed-user-sentence. (u-sentence)
but your token control includes interjection splitting, so you will see “hello, how are you” as two sentences from chatscript and therefore I presume count it as 2, not as one unprocessed user sentence.

Thanks Bruce!  I’ll try those suggestions!  Most of them are areas I still need to learn.

I was a little nervous about how long ‘_0 would last so I was conservative and used a user variable that wouldn’t break on me by surprise when I changed code elsewhere, at the cost of burning a little more ram and time, at least during development.  I’m sure you’re much more concerned about how long it will take when 1000 users are all on simultaneously.  I have max of three users at a time.

I knew about $$vars versus $vars.  The reason I used global variables not temporary local variables was to be sure they would still exist when I’d left that topic (~COUNTEM) and was off in some other topic in simpletopic.top. ( so they print out when you type “What is your name” for example, in that code.)  I wasn’t sure, and still am not sure,  if $$tmp would still exist when I have moved off to ~INTRODUCTIONS.  If it does, (a) I’ll change it and (b) I’ve learned something more about the scope and lifetime of $$ variables.

At least I touched simplecontrol.top and took most of the static-cling newness off it so I’m closer to being able to modify it when that’s the right thing to do.  One step at a time.

Wade

_0 vars last for the duration of the “rule” at a minimum.  They disappear at the end of the volley but may be overwritten by any rule that reuses them.  So since typically no rule requires 10 or more fields to memorize, you can assume _10 to _19 last forever during a volley (if you want to stash stuff there).  Typically _6 and on would be safe depending on your rules.

$$vars last for the duration of the volley (until the user is complete and written out to USER directory). Has nothing to do with topics. So a $$var lasts until the POSTPROCESS phase is completed and there is nothing more for the chatbot to do to handle the input from the user.