I learned Promela and Spin, but when I try verifying the model, these lines
are returned to me.
What do they mean?
Thanks
That means that you ran a Spin verification and your verification identified an error. Your next step is to determine how the error occurred. You do that by generating and examining the 'trail file'.
If you performed your verification as:
$ spin -a model.pml
$ gcc -o pan pan.c
$ ./pan
then examine the trail using the model.pml file with:
$ spin -p -t model.pml
Probably, you have a deadlock or other error in your model.
If you would post your complete console output, I could probably update this answer to give you more information!
Related
I have created redis cloud subscription and followed the instructions as mentioned in this document https://github.com/RedisGraph/redisgraph-bulk-loader. I am seeing error when I followed the instructions. I have also tried to use example2 csv but received the same error. Error : "Python int too large to convert to C long"
redisgraph-bulk-insert GRAPH_DEMO -n example/Person.csv -n example/Country.csv -r example/KNOWS.csv -r example/VISITED.csv
-h ***** -p ***** -a ********
I also received this message while trying to insert csv data (all data was quoted to be imported as string) into a graph. So what I did was to simply comment this line csv.field_size_limit(sys.maxsize) in entity_file.py. It worked in my case, but I don’t think this would be safe for every use case.
I have a custom sniffer, which produces output in pcapng format. I launch it like that:
<sniffer launch line> | tee out.pcapng | tshark -Tpdml -i -
expecting to have a pdml output in stdout. Generally it works, but sometimes the following happens: after the first packet was written to stdout by sniffer, tshark just reports 0 packets captured and closes. At the same time the out.pcapng appears to be valid and successfully can be opened with wireshark.
Moreover, when I try cat out.pcapng | tshark -Tpdml -i -, it would handle the input successfully in 90% of launches, but would still fail sometimes.
It seems, that changing tshark flag from -i to -r helps, but I'm not sure if it solves the problem or just make it appear less often. And anyway, I'd be pleased to know what actually happens there. Launching tsahrk with stdbuf -o 0 tshark ... doesn't help.
An example of problematic .pcapng file: https://drive.google.com/file/d/1GS41yti0zs5-ZT5bgRNYslIQW1q_fDfQ/view?usp=sharing
Version of Tshark: TShark (Wireshark) 3.2.3 (Git v3.2.3 packaged as 3.2.3-1)
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.
So this is the only thing I see on failed build. When running npm scripts on a cli, you usually see more than the exit status. Is there some option to view the entire cli output instead of this pseudo log?
I contacted support and was told to cat the debug log in order to see the output.
#!/bin/bash
set -ex
cat $(find $HOME/.npm/_logs -name '*-debug.log')
I'm attempting to setup a new compute cluster, and currently experiencing errors when using the qsub command in the SGE. Here's a simple experiment that shows the problem:
test.sh
#!/usr/bin/zsh
test="hello"
echo "${test}"
test.sh.eXX
test=hello: Command not found.
test: Undefined variable.
test.sh.oXX
Warning: no access to tty (Bad file descriptor).
Thus no job control in this shell.
If I ran the script on the head node (sh test.sh), the output is correct. I submit the job to the SGE by typing "qsub test.sh".
If I submit the exact same script job in the same way on an established compute cluster like HPC, it works perfectly as expected. What setting could be causing this problem?
Thanks for any help on this matter.
Most likely the queues on your cluster are set to posix_compliant mode with a default shell of /bin/csh. The posix_compliant setting means your #! line is ignored. You can either change the queues to unix_behavior or specify the required shell using qsub's -S option.
#$ -S /bin/sh