development loop for CLIPS - expert-system

I'm a rank beginner to CLIPS expert systems shell. I'm on Win7
I'm having trouble finding a good compile/test/debug loop.
To make the question really concrete, consider the animals.clp file that ships with CLIPS
When it thinks it knows what animal it is, it prints "I guess it is a "
What would your actions be to modify that to "I will guess it is a ", check that it
works with the new wording, and then change it to "I think it is a "
My current answer to this is
modify file in external editor to "I will guess it is a "
start clips
load file with load menu or (load )
(reset)
(run)
exit clips
modify file to "I think it is a "
start clips
load file with load menu or (load )
(reset)
(run)
Surely there's a way to avoid doing all this, but I can't seem to find a 'reload' command

There is no need to exit CLIPS. You can just issue the (clear) command (which has the same effect as exiting and restarting CLIPS), then (load ) (reset) (run).

Related

How do I close a file in the terminal

I've only started doing python3 for a paper at university. I don't plan on continuing after this semester is over but I want to do the best I can in this class. However, I am having difficulties with seemingly a basic task.
I've opened a file using f = open() and I've accessed it in the terminal using less. It displays everything out nicely but it doesn't let me close the file or even continuing to code past the printed text.
It just repeats ~ on separate lines and finishes with a highlighted (END)
By typing q, you will be able to exit it

Debugging non-responsive python/PyQt application in PyCharm

How do you go about debugging a non-responsive python/PyQt application in PyCharm?
I am an experienced programmer, but new to all thing python. I have been given a large application (36,000 lines), which works under Windows, to port to Linux.
Having made just a handful of changes for OS-specific stuff, when I run the application it comes up with its main window. But then after a few seconds it becomes dimmed, and when I close the window I am asked to confirm to end "the window is not responding".
(Aside: On a whim I decided to try running the app via sudo, and surprisingly it works fine. I have tried doing strace running as root versus non-root, but I'm fairly sure there is nothing obvious in the way of file accesses/permissions etc. that differs. This may be a clue, but just as likely to be a red-herring, e.g. if it's an "uninitialized variable".)
If I debug it inside PyCharm, at that point I expect to click the "Pause Program" button, so that I can get a trace back and begin to see where it is in the code, and start stepping or whatever. However, that button does nothing at this stage? Maybe it only "works" when on "a python instruction"?
If I force a core dump (from the keyboard) and examine with gdb, I can see that the stack frame shows it is way down inside libQtCore/libQtGui, in processEvents on a call to read.
So how do I begin to go about debugging why it is (presumably) busy doing something at this point, or at least not responding? Any tips would be welcome. I do hope this question will not fall foul of SO's "too general" policy, any tips to get someone going on debugging a "non-responsive" program would be welcome.
To answer my own question, since no responses seem to be forthcoming.
In this case, the problem turned out to lie in a file which is imported into other files, named pyperclip.py. That had code outside of any function, and in a path through the source executed under Linux but I think not under Windows, which included:
app = PyQt4.QtGui.QApplication([])
cb = PyQt4.QtGui.QApplication.clipboard()
Clearly some attempt to gain a clipboard object. For whatever reason, this appears to work when run as su, but when run as the logged on user it causes the whole application to "hang". Removing those two lines solved the unresponsiveness.
In terms of what I learnt from this for debugging unresponsive applications: you need to debug not from the entry point of the program, as I would have expected, but rather right from the start of each file, and actually step into each import line just in case it is executing some initial code. Horrible!

Autostart GUI application with LXDE session

There's quite a bit of information out there on this topic, but for some reason I just can't get it to work. This is on a raspberry pi running the 'DietPi' flavor over the raspian distro, and is perhaps what separates my question from the others.
So I have a GUI application that I wish to launch at boot, after the LXDE session has begun. So I have utilized the following file here:
/etc/xdg/lxsession/LXDE/autostart
and added the line:
#/myapplication
This works, however, it launches multiple instances of this program, and the first one always crashes. This creates problems because there's some competition for resources (IO, files, etc). So what I did was create script file, /myapplication-autostart.sh instead like so:
if pgrep "myapplication" > /dev/null
then
echo "my application is already running"
else
/myapplication
fi
and then changed /etc/xdg/lxsession/LXDE/autostart to #/myapplication-autostart.sh. Now what I find is the program launches once, but the instance crashes. It crashes when it attempts to create a window (opencv imshow). This is strange because the program will also run headless if an X-session is not available, but for some reason it crashes and I do not know where to check why.
Also, to test it wasn't an issue with the script file, I commented everything out except the /myapplication and I have found the script file runs in a continuous loop and every time I close the application it opens back up. I'm not sure why this is either.
I've tried adding a sleep delay in the script and it does not help. For whatever reason, it seems the LXDE autostart script is ran at least 3 times when booting the pi and the circumstances around the first cause the program to crash. Does anybody understand this sequence and behavior of calling this autostart script?
It is also possible to use the XDG standard Autostart - which is independent of the used desktop environment - by placing desktop files at
$XDG_CONFIG_HOME/autostart (by default ~/.config/autostart)
or for system-wide autostarts at $XDG_CONFIG_DIRS/autostart (by default /etc/xdg/autostart).
Such a .desktop-file could look like:
[Desktop Entry]
Type=Application
Version=1.0
Name=JDownloader
Exec=/usr/local/bin/my-application.sh
Categories=Utilities
The specification of desktop-files can be found at freedesktop.org.
Here was the final solution...
/etc/xdg/lxsession/LXDE/autostart added the line:
/myapplication-autostart.sh
and /myapplication-autostart.sh was changed to:
#!/bin/bash
if pgrep "myapplication" > /dev/null
then
echo "my application is already running"
else
if [[ "$DISPLAY" = ":0" ]]
then
/myapplication
fi
fi
I had to write the display variable to file in combination with the errors to file to discover the issue. At login 2 X sessions were created, display ":1" and display ":0", in that sequence. Display ":1" crashed because, although not headless, it was not initialized to a particular resolution and there was some resizing code in my program. Display ":0" was the actual display on the HDMI out and the one I wanted. Really, the conditional check to see if the application isn't necessary but I left it in there to be safe. I could have also left the # on the LXDE autostart file but it got annoying in the cases I wanted to close the application because it'd keep re-opening. Possibly I'll put it back later.
Thanks for the help!
First, some comments about opening several instances of the program: when you use "#" at the beginning of the line on the startup file (ex.: #/myapplication), this requests your system to try to launch the program, but if the program fails to open correctly, then the system will try to open it multiple times until it opens correctly -- if you remove "#" from the line beginning, then the system will only try to open the program once.
Now, to find out why the program is failing, I advise you to add
2> /file/log
to the end of every command on your script. Doing so would append any error message to a log (/file/log), and analyzing those error messages would be key to find out why the program is misbehaving.
One important note: if your program needs root privileges to run, then it will fail when called via /etc/xdg/lxsession/LXDE/autostart, as this method calls programs without elevated permissions.
This is an old thread but I was having problems getting autostart to start all the tasks listed. After many days I concluded there were one or more "invisible" characters that autostart didn't like. So I deleted the lines for the tasks that didn't start and retyped them. That solved the problem!
I think I corrupted the lines because I was editing some of the lines on my Windows computer. It was likely inserting CR with LF or some other stuff. I WILL NEVER EDIT TEXT FOR LINUX USING WINDOWS!
Maybe someone else will hit this problem and this may help them. I don't know where else to put this information.

'modifying' an exe by working with bas using visbasic or q basic

all!
I'm trying to run programs to control stepper motors. The PC and software and stepper motor controller I have already in place are pretty old and I'm new to almost everything I'm doing here-learning as I go sort of thing. I've 'coded' a bit in Matlab, so I have a very basic level of coding logic, but basically no knowledge of any common syntax. So, I know some about the steppers and the stepper controller, but not much else!
I have a program called "Hoop.exe" that I'm trying to modify to slow down the speed of one of the steppers (I just need to change a 300 to a 200!) when I run the program. There is also an associated (assuming) hoop.bas and a hoop.txt file on the floppy disc. From looking at the txt file, it looks like basic code from examples of basic I've seen. I'm working with visual basic 2.0 and qbasic 1.1 on Windows 98.
So, I tried opening the hoop.bas file first with qbasic and with vb. With qb, I get a 'bad file mode' message. With vb, I get 'invalid file format' and it seems it wants me to open a mak file but I have no 'hoop.mak'. I did this thinking that I could open the bas file with vb or qb, and then edit it, and then save it as an exe, and then run that.
I found a pdf that showed how to incorporate a qb file into the command button of vb, and I tried that. But, I got an "Expected: end of statement" error in the first line! when I tried to save it as an exe.
So, all I really want to do is change my hoop.exe. I would assume that since qb and vb are both on the PC, one of them wrote the bas (maybe not!), so I'm wondering why neither of them can read it.
I've never used vb or qb, but if I have to get into the nitty gritty, it seems like I'd rather use qbasic, since I've never used a graphical interface to code before. But, is either one of those necessary in order to do what I want to do? (I'm going to need to write some programs to control these steppers when all is said and done, but I figured that I should take it one step at a time.)
I tried some form of copying and pasting into qb, but I couldn't immediately figure out how to do that. (Probably because I have no idea how to use qb.)
So, what would be the most efficient way to modify my hoop program?
If the answer is that I just need to learn basic with qb, that's fine, but I'd like to get some sort of indication from people who know what they're talking about before I put that much effort in.
I would really appreciate any pointers because I'm apparently completely clueless on my own!
8/10/2013:
Just in case it's helpful, here are some lines from the Hoop.txt I opened:
10 CLS : CLEAR 1000: P = 512
20 LOCATE , , 1
100 A% = INKEY$: PRINT A$;
105 IF A$ = "*" THEN GOTO 700
110 GOSUB 510: GOSUB 610: GOTO 100
500 REM
510 IF A$ = "" THEN RETURN
etc. This is the beginning of the interface code that allows me to talk to the motor controller
QuickBASIC and Visual Basic are very different, despite their common name of "BASIC" and despite the fact they were both made by Microsoft. First you need to determine if the .BAS file is QuickBASIC or Visual Basic. A simple quick way (though not the most accurate) is to open the file up in Notepad or some other text editor. If keywords such as "OPEN" or "LEN" or "MID" or "CLOSE" are in uppercase, then its more likely a QuickBASIC file. If the keywords look more like "Open" or "Close" or "Len" or "Mid", then its more likely a Visual Basic file.
Now keep in mind that there are other versions of BASIC that have been developed, such as Turbo BASIC (Borland's version) or GW-BASIC or BasicA or PowerBASIC and even Color Basic.
Now if you can't figure it out this way, the next thing I'd suggest is downloading a hex editor, such as XVI32 (though there are many other free ones out there). Look through the file (especially towards the end of the file) and there are usually signs that indicate what kind of compiler was used. You might see the words "Microsoft Basic Compiler" or "Borland Turbo Compiler". Usually towards the end of the file, there are string "stubs" put in by the compiler or linker that you can use to determine the compiler.
If all that fails and you are desperate and that "300" number is hard coded in the program and you need to change it, then there is another way to do this. First back up your original exe file. Then Use XVI32 or some other hex editor and search for the string "2c01" (300 is 012c hex and you need to reverse the 01 and 2c since Intel machines are little-endian). Once you find an instance of 2c01, change it to "c800" (200 is 00c8. Little Endian version would be c800). Save the file, then rerun it. This is a gruesome trial and error way to fix this. If it was changed from 300 to 200, then everything is good! If not, restore from your backup and try again!
Have you considered getting an Arduino or some other low cost and friendly electronics development platform? I think it would be the way to go for you to control stepper motors...
take a look:
http://arduino.cc/en/Tutorial/StepperUnipolar
If you google around you'll find tons of you tube videos showing off some arduino controlled stuff.
Modifying your current .exe seems to me a too long and hard path to follow instead of making your own and proper source code for achieving what you want, as you would need to disassemble the executable file and literally "know what you're doing" with all that assembly language to find where to patch the binary with the right value.
Anyway, if you post a picture or a schematic of your old hardware I could try to help you a little more, but I guess that would be better suited to this other stack exchange site:
http://electronics.stackexchange.com

Is EOT character sitting over terminal promp an issue?

Warning: you know how they say "there's not such thing as a stupid question"? Well, this one is, or, I suspect it's really minor, but wth, why not ask. Search engines didn't bring me anything remotely useful, though that could be bad searchterm-fu.
I recently downloaded sqlite3 onto Ubuntu 10 to start learning SQL commands. I un-tar'd 3.7.12.01 and make installed.
After creating a test.db with create table test (id) I decided to see what I'd get if I cat it. Just because.
The result is an EOT character (u+0004) which is sitting right over my prompt. Illustrated screenshot: http://imgur.com/omfMa
I realise this is not the type of file you would use cat on. I only want to know, before I go further,
does the strange placement of this character signal any future issues when actually playing around with SQL, or some issue with newlines, or fonts (this is monofur set at a high font size) or similar?
I've never seen a result character placed directly over my prompt before.
The character is placed over your prompt, because it is a double-width character, and terminals in general are not good at handling double-width characters. It does not mean anything.
There are some control codes which can do very funny things with your terminal, such as changing colors, fonts etc.
But none of them do really harm - you should be able to reset your terminal to a healthy state, or close it and open a new one.

Resources