AI Zone Admin Forum Add your forum

NEWS: Chatbots.org survey on 3000 US and UK consumers shows it is time for chatbot integration in customer service!read more..

Working on a ChatScript Editor
 
 

Hi,

To help myself not get lost while writing chat script files, I’ve started work on a editor/IDE for ChatScript. It’s current very basic , but I thought that I would post it here so people could have a look and see if they think it would be useful and hopefully give me some feedback.

First I should say that the version attached doesn’t even allow editing, its currently reading only as I’m still working on the editing/saving part. So as it doesn’t ever save anything to your files it shouldn’t be possible for it to corrupt any file, however as with any application that is in the early stages of its development you should always make copies of your files and then use it with those copies.

This is a .net application, so on windows you will need the .net 4.0 framework installed. I would think most windows computers would already have that version installed by now. The application also “should” work under mono so it “should” work on linux or Mac if they have mono installed. However I haven’t even tested it under mono on windows so can’t say for sure that it would work on anything other than a windows computer.

Now on to trying to explain how to use/test it. When it first opens you will see that the window is divided into two parts, on the left is a list section (currently empty) and on the right is the text section (also currently empty).

So you need to open a file, which is done by using the file menu and the load file option.

Once you have selected a ChatScript file in the dialog, then that file will be loaded and in the list section of the window will appear a root node with the name of the file and then under that a list of topics and concepts that are in the file. In the text part of the window will appear the text of the topics and concepts. Note this will be slightly different to the plain text of the file, as currently the parse process, that the application uses, strips some of the formating off (again this change isn’t actually saved to the file, so your file will be unchanged). As a example, most tabs are stripped.

If you expand the topics then you will see child nodes under them, one for each rule in the topic. Currently these child nodes only tell you what type of rule it is (t, s, r, u, ? ).

Now when selecting a topic or a concept in the list, then one of two things happen: (selecting a child rule node has no effect at the moment)

1: by default the application will clear the text window and then only display the text that makes up the selected topic or concept.  Selecting another topic or concept will again change the displayed text to the revelant text for that selection. To view the whole file again (all topics and concepts) you need to select the root “File: <name of file>” at the top of the list.

2: the application also has scroll mode, where the text window will always display the whole file but it will auto scroll to the position of the selected topic or concept. To enable this mode you need to select “Scroll To Topic” in the options menu. Also once you have changed to this mode, if you had only a concept or topic text being displayed in the text window, then you need to first select the root “File: <name of file>” item in the list. After that you can select a topic or concept and the text window will scroll to its position.

I’m not that great at writing instructions on how to use a application, so I think these instructions make it sound a lot more complicated than it is.

There is also so very rough/basic colour coding of the text. Text like “topic:”, “concept:” “u:” should be colour coded, but there is some problems in that it doesn’t alway find all the words that should be coloured. You also can turn this on or off from the options menu and the “colour coding” item in that menu.

It is also possible to have multiple files open/loaded at the same time. While in the default mode, when you select on a topic/concept in another file then it will automatically display the text for that selection (all files and there topics will be in the list). However in the scroll to topic mode, currently you will need to manually select the root node of a different file first and then after that you can select the topic/concept.

Now as I said this is a very early stage for the application and it needs a lot of work. It currently can’t read some valid ChatScript files, like it can’t read the default “simplecontrol.top” file. I’m working on finding out why it can’t parse that. But most simpler files work mostly okay. The default “simpletopic.top” works with two minor problems in that the application currently doesn’t ignore comment lines so it tries to parse those lines.

So at the start of the file it thinks the line:

#It is well commented with annotations for :abstract and :verify. 

Is defining two new rules that have type “for:” and “and:”. However this has no actual effect at this stage as they are just listed as a extra two rules under the CHILDHOOD topic.

So I need to do quite a bit more work on the parse.

I’m sure if you just have a quick test of it, then how it all works will be clearer than I’m explaining here.

So I would really like to hear what people think of it and any suggestions.

File Attachments
Editor.zip  (File Size: 22KB - Downloads: 203)
 

 
  [ # 1 ]

I forgot to add that one of the things I hoping to find out by having people test this at such a early stage is which is the more popular mode? The one where it only displays the topic or concept that is selected or having it autoscroll to the selected topic/concept.

Another thing I’m hoping to find out is what sort of percentage of chatscripts it can currently read without major problems.

Also if there is any interest in a custom editor or do most people already have their favourite editor that they are unlikely to change from. I will most likely work on it just for my own use even if there is no interest, but I always find that I spend more time working on something if I know that other people are/will be using it.

 

 
  [ # 2 ]

As the guy with the most chatscript files….. email me your email address. There is no point in filing bug reports via this forum.

 

 
  [ # 3 ]

Great idea, too bad it’s windows-centric.

regards, Richard

 

 
  [ # 4 ]

It looks like a good start, Matt. Keep up the good work! smile

A couple of questions, though. I see that it’s .NET, but I didn’t see mention of which language you’re using (e.g. VB, C#, C++, etc.), and I’m curious. Also, will you be sharing the source files at any point? smile

 

 
  [ # 5 ]
Richard Kappler - Nov 20, 2012:

Great idea, too bad it’s windows-centric.

regards, Richard

It should hopefully run on other OS’s if you use mono (http://www.mono-project.com/Main_Page). The only slight uncertainty I have about it working with that, is mono’s support for the .net windows forms api. I know a few years ago there support was rough in places but I think they have fixed those issues now. So really I would be surprised if this didn’t run on linux with mono installed.

If someone would like to test it on linux and a mac then that would be very helpful as I might be able to fix any issue that does stop it working.

 

 
  [ # 6 ]
Dave Morton - Nov 20, 2012:

It looks like a good start, Matt. Keep up the good work! smile

A couple of questions, though. I see that it’s .NET, but I didn’t see mention of which language you’re using (e.g. VB, C#, C++, etc.), and I’m curious. Also, will you be sharing the source files at any point? smile

It’s C#. Incase you are interested I’m currently using the sprache library to parse the script files: http://code.google.com/p/sprache/ . However I have hit some problems in getting it to work in all cases and as that library no longer seems like it is under development, so I might change to another parser library. Most likely Irony: http://irony.codeplex.com/ .

As for sharing the source files, I will almost certainly be releasing them once I get it working properly and tidy up the code.

 

 
  [ # 7 ]

That’s awesome, Matt. Sadly, however, C# isn’t a language that I’ve learned yet. I’ve dabbled a little with VB.NET, but never took the time to learn any flavor of C, and I often kick myself over that fact. downer

 

 
  [ # 8 ]

With the help of Bruce pointing out what sort of files doesn’t work with the last version of the “editor”, I’ve been able to improve the parsing code. This new version will read all the scripts that I’ve tried it with. Which is simplecontrol, simpletopic, skeleton, a random seletion of the default worlddata files and some of my own scripts.

If for no other reason, I find it really helpful in just being able to clearly see what topics are in the skeleton file.

With this new version, I’ve actually rewrote all the parsing code, so at the moment there are a few changes from the first version. One change is that it currently doesn’t show the rules under a topic in the side list. So that list will only show top level categories like: topics, concepts, tables, outputmacros and patternmacros (not sure if I’m forgetting any top level categories). Plus with some files it will show a “file comments” category as the first node under “File: <filename>”. This is because my parser groups together any comments at the start of a file into their own group. Really I guess they should be part of the first real categories.

However with comments in general it’s hard to tell if which “category” they belong to.

For example those first comments in a file could be general comments about the file or could be comments related to the first topic/concept/whatever. The same goes for other comments in the file. If you had a comment just above the start of a new topic, its hard for the parser to know if that should belong to the last declared topic or to that new topic. So I’ve gone with including comments with the last declared topic. This creates some problems when using the default mode where only a single topic/concept/etc is displayed as any comments placed before the topic was declared wouldn’t show up.

For example, the start of simplecontrol is:

# this function is executed once for every new user chatting with harry
outputmacroharry()  # you get harry by default
$token #DO_INTERJECTION_SPLITTING  | #DO_SUBSTITUTES   | #DO_NUMBER_MERGE   | #DO_PROPERNAME_MERGE  | #DO_SPELLCHECK | #DO_POSTAG  | #DO_PARSE
^addtopic(~introductions)
$control_pre = ~control
$control_main 
= ~control
$control_post 
= ~control
$userprompt 
= ^"$login: >"
$botprompt = ^"HARRY: "

# this function is executed once for every new user chatting with georgia
outputmacrogeorgia() # you can request georgia by giving  name:georgia   as your login
$token #DO_INTERJECTION_SPLITTING  | #DO_SUBSTITUTES   | #DO_NUMBER_MERGE   | #DO_PROPERNAME_MERGE  | #DO_SPELLCHECK | #DO_POSTAG  | #DO_PARSE
^addtopic(~introductions)
$control_pre = ~control
$control_main 
= ~control
$control_post 
= ~control
$botprompt 
= ^"GEORGIA: " 

With my editor the first comment is in its own group. While the next “# this function is executed once for every new user chatting with georgia” comment is actually part of the outputmacro: harry()  macro group. Where we can clearly see that it is related to the outputmacro: georgia() macro, but the parser can’t really tell unless I set some rules like a comment on the line before a new group is declared is part of that new group.

Maybe I need to include a chatbot into the editor so that it can try to work out what comments are related to smile

File Attachments
Editor.zip  (File Size: 28KB - Downloads: 159)
 

 
  [ # 9 ]

I haven’t recieved any feedback on the last version, so I can only take it that it is reading most script files now.

Today’s version adds basic support for editing and saving the changes. So first I need to give the warning about not testing it on important scripts. Always make backups of your files. Personally, I have created a seperate folder and placed copies of my scripts in there, and then only use the editor with files in that folder to make sure I don’t accidently use it with my original scripts. I know this is all common sense, but I feel I did to give this warning as the editor is still in a early stage of development and it is very likely to have bugs in it. So I don’t want it to be responsibly for any data loss.

First a note: In the rest of this message, I’m going to use ‘topic’ to mean any top level item, like concept, topic, table, macro.

At the moment editing only works in the default mode where each topic is displayed on its own after it has been selected from the side list. So to start editing, you open a file and then select a topic from that side list. The text window will then only show the text for the seleted section of the script. You now do your editing in the text window. At any point you can change to another section and then change back and as expected your changes will still be there.

However if you had added a new topic then the application will still be considering it as part of the orignal topic and it won’t be listed in the side list. To make the editor aware of the new topic, you must make sure that the original topic that it is part of, is selected and then in the Analyze Script menu, select parse selected (which at the moment is the only item in that menu). The editor will then try to parse your changes. As long as the editor thinks it is valid chatscript then you will see the new topic is listed in the side list.

I think a quick example will help to show what I mean. So if we opened a file with the following code:

topic: ~section1 ()

u: () test rule.

concept: ~secion2 (test)

topic: ~section3 ()

u: () another test rule 

Then in the side list would be three items. One for each of the topics and concept. If you selected the “concept: ~section2” item, then only the single line of that concept would be displayed in the text window. If you now changed the code of that concept to the following:

concept: ~secion2 (test)

topic: ~newsection ()

u: () new test rule 

Then the editor would still only be listing the original three topics/concept in the side list, and the new topic: ~newsection would still be classed as part of the ~section2 concept. To make the editor aware of the new topic, you would make sure that the “concept: ~section2” was selected in the side list and then go to the analyze script menu and select parse selected. This will make the editor reparse that section of the script and it will then know that there is actually a new topic in there. So after you have run the parse selected, you will see that the side list is now : topic: ~section1 , concept: ~section2 , topic: ~newsection , topic ~section3 . As you would expect.

If you aren’t adding a new topic/concept/etc then you don’t “need” to run the parse selected, but it is most likely a good idea to anyway. It will also point out some invalid code. For example if I had changed the original concept code to :

concept: ~secion2 (test)

u: () new test rule 

And then had ran parse selected on it. I would have got a error message telling me that the “u:” was unexpected. This is because a concept can’t have rules in them. It would have also highlighted the “u” in the text window. Currently it would have only given a message like that if it found one of the top level rules (t: , u: , s: , r: , ?:), but would have been happy if I had placed a responder in there. As it currently doesn’t check for responders. It also would have given the same result if I had placed a top level rule in a macro or table.

Ok, so now we have made our changes to the script, so we want to save it. To do this you need to select the file from the side list. So if our script file had been called “test.top”, at the top of the side list would be “File: test.top” (all the other items in the list would be children of this node). So we select “File: test.top” and then in the text window we will see the whole file once again, with our new topic in the correct place. Then we simply go to the File menu and select “Save As”, select where we want to save it to (and its file name) in the dialogue, and that’s it. I have only given a “save as” option at the moment to make sure you don’t overwrite any important file.

Currently editing and parse selected is disabled when in the “scroll to topic” mode.

Some other changes in this version are:

* renamed the application to “ChatScriptEditor” as it can only just claim to be a editor, never mind a IDE.
* when opening a new file, if it can’t parse the script then it will display the whole text of the file in the text window and highlight the point where it had trouble parsing the script. So it will give the same sort of result as if you had of ran parse selected on a section of code that included invalid code.
* will now handle and ignore comments, so it won’t believe that a “topic: ” in a comment is a real topic, or a “r: ” is a actual rule. . The same goes for “quotes”, it won’t try to parse them into rules or topics.

 

File Attachments
ChatScript_Editor.zip  (File Size: 27KB - Downloads: 165)
 

 
  [ # 10 ]

will now handle and ignore comments, so it won’t believe that a “topic: ” in a comment is a real topic, or a “r: ” is a actual rule.

Sad…. since r: is a valid gambit rule.  THe valid gambits are t:  x:  and r:

 

 
  [ # 11 ]
Bruce Wilcox - Nov 21, 2012:

will now handle and ignore comments, so it won’t believe that a “topic: ” in a comment is a real topic, or a “r: ” is a actual rule.

Sad…. since r: is a valid gambit rule.  THe valid gambits are t:  x:  and r:

I meant that a r: (or a t: or a u: etc) inside a comment line or inside a quote won’t be considered as a rule. In the previous versions it wasn’t handling comments or quotes so if you had the following code:

# yet another comment before the following r:  rule 
r:  this is the real rule 

The editor would have actually thought there was two r rules in that code as it wouldn’t have realized that the first one was inside a comment line.

The same goes for quotes.

uTestHandler  () Your message has been handled by the " u: TestHandler" rule

In this new version, it will know that there is only one rule defined in that code, but in previous versions it would have actually have thought the “u: TestHandler” quote was defining another u: rule. So all I meant is that it now behaves as it should in this regard and doesn’t miss parse those things.

However I had forgot about x: being a valid gambit. So need to add that to the rule handling code. Having a x: in a script with this version will still work, it’s just the editor won’t realise it’s a rule so if you placed a x: rule inside a concept, it wouldn’t tell you that it shouldn’t be there.

 

 
  [ # 12 ]

Matt, please bear in mind that, for some of us, this is an extremely busy time of the year, and that we may not be able to get to this right away. As a moderator, I read all the posts as soon as I know about them, but seldom these days can I act on them right away. However, I will get to it at some point. smile

 

 
  [ # 13 ]
Dave Morton - Nov 21, 2012:

Matt, please bear in mind that, for some of us, this is an extremely busy time of the year, and that we may not be able to get to this right away. As a moderator, I read all the posts as soon as I know about them, but seldom these days can I act on them right away. However, I will get to it at some point. smile

Hi Dave, I completely understand that, sorry if I gave any impression that I was being impatient. I can only guess that when I said about not having got any feedback about the last version, that it came across like that. It wasn’t how I meant it. I just meant that I think the editor is currently reading script files ok. Sorry for any misunderstanding

 

 
  [ # 14 ]

No worries. I just wanted to clear up any misunderstandings, is all. And I didn’t think you were being “impatient”, per se. just a bit… Er… Um… enthusiastic. raspberry

 

 
  [ # 15 ]
Dave Morton - Nov 21, 2012:

No worries. I just wanted to clear up any misunderstandings, is all. And I didn’t think you were being “impatient”, per se. just a bit… Er… Um… enthusiastic. raspberry

Hmm…enthusiastic smile

Well I’m writing this editor mainly for myself. I quickly found that even only having a handfull of script files was becoming a real pain to manage. Trying to remember what topic was in what file and where it was in the file. I’m just used to Visual Studio. So I decided that the time it took me to write a simple editor would be worth it in the long term. The editor is now reaching a point where it is usable for my requirements, so I expect the time I spend on it to drastically fall soon.

So that and the fact that I have been involved in a number of opensource projects before where the rule has been to release as often as possible, resulted in the posting of the three versions. I really should set up a simple webpage and host it on there instead of keep posting new versions to this forum.

 

 1 2 3 > 
1 of 3
 
  login or register to react