I wrote a model in Spin. I want to check some LTL on the model.
for example:
ltl L1 {<>[]Working}
in the Verification window i choose option "use claim" and click "Run":
ltl L1: <> ([] (Working))
gcc -DMEMLIM=1024 -O2 -DXUSAFE -w -o pan pan.c
at this point I have no idea what to do next...?
I've tried to look for the answer with Google but there are no guides how to use Spin....
Save your model including the ltl-block in foo.pml
spin -a foo.pml
gcc -o foo.exe pan.c (Windows)
foo.exe -a
Running the executable with -a is the key, otherwise, the LTL-property won't be checked.
In the 'verification' window after your click 'run' there should be a verification result. It looks like this (for example):
verification result:
spin -a foo.pml
ltl ltl_0: [] (foo)
gcc -DMEMLIM=1024 -O2 -DXUSAFE -o pan pan.c
./pan -m10000 -a -c1
Pid: 21462
(Spin Version 6.2.4 -- 21 November 2012)
+ Partial Order Reduction
...
pan: elapsed time 0 seconds
No errors found -- did you verify all claims?
Are you not seeing any of that? Or are you seeing something but can't interpret it?
Related
I need to rsync to a remote server using a non-standard SSH port and 2FA which I use via Authy app. The SSH works with this command:
ssh -2 -p 9999 -i /Users/Me/.ssh/id_rsa user#9.9.9.9
This brings up a "Verification Code" prompt in the shell. Which I enter from Authy, and I'm in.
Given the discussion on this a StackOverflow answers I tried this variation of rsync:
rsync -rvz -e 'ssh -p 9999 -i /Users/Me/.ssh/id_rsa \
--progress /src/ user#9.9.9.9.9:/dest/
(Put here on two lines just for legibility, it's one line in my shell command).
This does bring up the Verification Code prompt, which I enter correctly, but then it produces this error:
protocol version mismatch -- is your shell clean?
(see the rsync man page for an explanation)
rsync error: protocol incompatibility (code 2) at compat.c(185) [sender=3.1.3]
How can I use rsync with 2FA? Many thanks.
Because #JGK mentioned the answer in the comment, adding answer here for posterity. This "is your shell clean" stuff is shown when remote server is echoing some output upon login, which in my case .bashrc indeed was. I've added a conditional to that echo only to apply when the shell login is "interactive", as mentioned in this Server Fault thread, and it works. Just for easier clarity, the IF condition reads as follows:
if echo "$-" | grep i > /dev/null; then
[any code that outputs text here]
fi
Many thanks.
I am trying to run qemu with code that my teacher provided so that we are able to work on our assignment.
This is being run in Ubuntu 18.04
LIBPATH=/usr/lib/gcc/arm-none-eabi/6.3.1/
arm-none-eabi-as -mcpu=arm926ej-s -g ts.s -o ts.o
arm-none-eabi-gcc -c -mcpu=arm926ej-s -g t.c -o t.o
arm-none-eabi-ld -T t.ld ts.o t.o -o t.elf
arm-none-eabi-ld -T t.ld -L $LIBPATH ts.o t.o -o t.elf -lgcc #-lstr
arm-none-eabi-objcopy -O binary t.elf t.bin
rm *.o *.elf
echo ready to go?
read dummy
qemu-system-arm -M realview-pbx-a9 -m 128M -kernel t.bin \
-serial mon:stdio -serial /dev/pts/2 -serial /dev/pts/2 -serial /dev/pts/2
And the numbers in the last line `-serial /dev/pts/#' are from running ps in the terminal and grabbing the number. All of this is in an executable file, and when I run the file the qemu screen does display, but when I press enter again I recieve this error message
unknown keycodes `(unnamed)', please report to qemu-devel#nongnu.org
I cannot seem to find any clear answer on how to solve this problem. I have tried uninstalling and reinstalling qemu a couple of time.
QEMU's "unknown keycodes" message is about key handling in its graphics window, and means that the host keyboard mapping you're using has some odd setup that it doesn't entirely understand. Usually this means that a few keys won't work right in the graphics window, and you can ignore it unless you're actually having a problem with them. The whole keycode system was completely rewritten in a newer version of QEMU, and this message doesn't even exist any more.
If your test program isn't expecting to use the graphical screen, then you can definitely ignore the message (indeed you could turn off the graphics screen entirely with -display none).
The command line options to QEMU you're using for the serial port look really odd -- you seem to be trying to connect multiple serial ports to the same host tty, which I'm pretty sure won't work right. Unless you're actually using serial ports 1 through 3, just drop those and use the serial port 0 that is set up with "-serial mon:stdio".
autossh -M 10984 -v -o "PubkeyAuthentication=yes" -o "PasswordAuthentication=no" -R 6889:localhost:22 user#rpi.local
The above command works. The one below doesn't.
autossh -M 10984 -E /home/pi/ssh.log -v -o "PubkeyAuthentication=yes" -o "PasswordAuthentication=no" -R 6889:localhost:22 user#rpi.local
It says,
/usr/lib/autossh/autossh: invalid option -- 'E'`
How can I specify a log file as the SSH option when passing it to autossh?
This is a limitation of autossh. The autossh source code contains a list of command-line switches which the program accepts. The list is apparently supposed to include all of the ssh options, but it doesn't include "E":
#define OPTION_STRING "M:V1246ab:c:e:fgi:kl:m:no:p:qstvw:xyACD:F:I:MKL:NO:PR:S:TVXY"
...
/*
* We accept all ssh args, and quietly pass them on
* to ssh when we call it.
*/
while ((ch = getopt(argc, argv, OPTION_STRING)) != -1) {
switch(ch) {
case 'M':
...
It seems there are a few workarounds at present:
Run autossh with standard error directed to the desired file:
autossh -M 10984 -v -o ... user#rpi.local 2>>/some/log/file
SSH instances launched from autossh should inherit the redirection.
Use the ssh "-y" option to log through syslog, and have syslog write the messages where you want them to be written.
Modify the autossh source code to add support for the "-E" option.
Report the issue to the autossh maintainer and hope he fixes it in a later release.
Do you think it's possible to compile ssh using the Intel compiler? I don't really know where to start and there's not much info on google, so I thought I'd ask the community.
I really want to take advantage of the compression performance improvements. My idea is to set up an unencrypted ssh tunnel (but with maximum compression) as follows:
ssh -N -g -f -C -o CompressionLevel=9 -o Cipher=none eamorr#172.16.1.218 -L 6999:172.16.1.218:3129
Any advice greatly appreciated,
Build instructions for OpenSSH can be found here: http://unixwiz.net/techtips/openssh.html.
When you do the ./configure steps you'll want to do something like ./configure CC=icc CXX=icpc in order to use the ICC compiler rather than gcc.
If you've done it right then when you subsequently do a make you should see during the build that the compile lines will start with icc ... or icpc ... rather than gcc ... or g++ ....
I seem to remember being able to print out (or locate) the specific switches that each -O<num> option turns on. Can you remind?
Thanks!
The list of new features on gcc 4.3 shows a way to do it, via an extension to the --help command line option:
gcc -c -Q -O3 --help=optimizers > /tmp/O3-opts
gcc -c -Q -O2 --help=optimizers > /tmp/O2-opts
diff /tmp/O2-opts /tmp/O3-opts | grep enabled
Note, however that I never tried that, only read about it. The documentation about this command line option is at http://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html#Overall-Options
If you ever read the list of new features on gcc 4.3, perhaps this was what you were recalling.
You may also try the good ol' manual
$ man gcc
at the subsection "Options That Control Optimization".
On many machines, 'info gcc' will produce a wealth of information. Using 'gcc -v --help' produced a very long listing of options from sub-processes (actually, 1001 lines on stdout, and 14 on stderr) on my Mac (PPC G4 and MacOS X 10.4.11).