I would like to print all states when checking my model. We do get a trail file when an assertion violation occurs but I want to see the states even when there are no assertion violations. How can I do that?
One option is to compile pan with the gcc flag -DVERBOSE and watch the full details of the verification run. Of course the run will take a while and will spit excessive output, but you will see all the states as they are visited (the format is not very easy to read, but may be sufficient for your purposes).
Another option to see the state graphs of individual processes is
./pan -D | dot -Tps | ps2pdf - pan.pdf
This will create a multi-page PDF where each page is a process (including the never claim).
Related
For more readability I would like to add spaces around the arguments in a service's check command. Running a nagios check outputs an error as it seems to want everything on one likeso:
One line check_command definition
However I would like to spcify the check command likeso:
separate lines check command
It’s not possible. Nagios parses configuration attributes by the logic “attribute value \n” so that’s how it has to look.
Other options include breaking it up into multiple check commands, thereby reducing the amount of macros. It’s hard to say since you don’t share the actual text.
On that note, do not share text in pictures. Ever. For any reason. Copy the text and format it as monospaced. If it contains sensitive information, redact it from the text, don’t draw on a picture. Sharing text as pictures is a great way to become very unpopular with colleagues, support personell, and anyone else you come in contact with who has to be able to access the actual text itself, or just want to be able to read it (they may use a screen reader).
I am getting the above error when trying to run a script produce to a report. It is a pre-existing script that has been run, successfully many times before. Research has told me that that it is something to do with the stack size? I’m running 10.2B02 in WRQ Reflections. Can anyone tell me what this statement means and how I look up the value of my –S.
Thanks,
Paul
-s is a client startup parameter. You mention "Reflections" so you are probably using a character terminal session. The -s parameter is on the command line used to start Progress (which might be inside a script). If there is a -pf somefile.pf on the command line then it is inside that "parameter file". If it is not specified the default value is 40. The maximum value is limited by available memory but setting it in the hundreds or even in the thousands is not unheard of.
You can also get the startup values by sending a SIGUSR1 to the _progres process that the session is running. I.e. kill -USR1 That will (safely) create a "protrace." file that includes startup parameters and a 4gl stack trace. The file will appear in either the current directory, the home directory or the temp-file directory (I forget which, just look for protrace*).
This error usually means that your code is manipulating a field that is too large. (Like the error says.) That might be for a lot of reasons.
One common possibility is string concatenation in a loop.
Or you might be calling lots of sub-procedures and passing parameters around.
If "nothing has changed" in the code then it probably just means that some data structure has grown slightly larger over time and increasing -s is really no big deal so long as it solves the problem.
If you keep having to increase it then it is more likely that you have some sort of coding issue. Maybe you're passing things by value that ought to be passed by reference or maybe you have run away recursion. Or something else. You'd need to provide a lot more detail to say for sure.
It is also possible (but unlikely) that you have a corrupt data record that appears to have a field in it that is too large. You could run "proutil dbName -C dbanalys" as an initial step to see if that is true.
Part of the error message is non-standard -- I'm not certain which log file it is coming from or how it got there (applications can write their own messages) but it seems that it might have something to do with trying to send an e-mail. So I'd be suspicious that either the list of recipients got too long or that the body of the e-mail is too large.
The output from my device drivers which also falls in the dmesg is getting printed out on my stdout.Is there a way to prevent this?
You may be able to solve your problem by dynamically adjusting the console log level.
http://tuxthink.blogspot.com/2012/07/printk-and-console-log-level.html
Suggests that you can do this by writing to a proc node:
echo "6" > /proc/sys/kernel/printk
Would set it to 6 in their example. I suspect setting it to 0 or 1 would suppress almost everything non-fatal to the system
Log entries should still be retrievable by dmesg regardless of this setting.
However, this will affect messages from all sources. If you want to change the behavior of a custom driver, consider passing it a flag which would cause program logic to suppress message generation, or generate output at less important log levels which you might set the console to ignore as above.
There are different levels of printing messages in printk().
Refer http://www.makelinux.net/ldd3/chp-4-sect-2 for different levels in printk(). Use lowest loglevel, it wont be dispalyed in stdout, but it can be viewed using dmesg.
In some code coverage tools you can "hide" certain lines of code from the coverage tool, so that those lines do not count towards the coverage totals. For example, some code might be run only in circumstances that are hard or impossible to test (such as certain hardware failures). Thus, you might get 100% coverage reported even though some code was not exercised.
Setting aside for the moment whether this is wise, is this sort of thing possible with Perl's Devel::Cover?
(Devel::Cover can ignore entire files, but I am interested in ignoring just a few lines in a single file.)
A lot of uncoverable code features have been implemented but they are not documented because I wasn't sure of the interface. However, it's been a few years since anything changed in that area.
Probably the easiest way to see how to use the features is to look at tests/uncoverable in the distribution (see https://github.com/pjcj/Devel--Cover/blob/master/test/uncoverable). If you can't or don't want to change your code you can use the .uncoverable file (see https://github.com/pjcj/Devel--Cover/blob/master/tests/.uncoverable) and the cover options as mentioned by toolic.
If you do this, be sure to use the basic_html report which will mark a construct as in error if you tag it as uncoverable but it gets executed anyway.
I really should get around to tidying everything up and documenting it.
According to the TODO file on CPAN, this capability is not currently supported, but the developers see it as a valuable addition:
Enhancements:
Marking of unreachable code - commandline tool and gui.
The cover script mentions promising options: -add_uncoverable_point and -delete_uncoverable_point.
Can we find out the list of process which are currently running on in iOS programmatically?
Somewhat similar to shown here
http://www.techet.net/sysstat/
shown at process tab
Suggestions are always welcome.
Thanks
See this other answer I literally just posted.
Take a look at the modified Darwin C-code I posted:
darwin.c
darwin.h
If you look in there, inside OS_get_table(), you'll find a bunch of commented out printf statements. If you uncomment and change those, storing the data in some kind of usable data structure, you can collect all this type of information.
Note don't just uncomment all the printf statements and expect that code to work, though. iOS has limits on the rate at which apps can write to std out, so you'll get throttled if you have tons of printfs in a short period of time.