I am using the Nitrogen version of Frama-c on Mac, and can't seem able to use
the "set" logic, as documented in the ACSL manual, e.g., I can't declare
a ghost variable as in "//# ghost set<integer> someSet;".
The frama-c program always complains about a syntax error in the line where a set is declared, no matter what.
I also tried "Set" instead of "set", other types in place of "integer" (e.g. "char*")and specifying "//# open set;" to import the module.
Maybe I need to specify some command line option? Executing "frama-c -kernel-help" it's not clear what that would be though.
Or maybe the Mac version (I downloaded the Intel binary version) is outdated and I should compile the latest source code ?
Thanks, best regards,
Eduardo
ACSL is an annotation language that exists independently of Frama-C, although some of the same persons work on both. From the point of view of usage of ACSL in a Frama-C plug-in, there are three levels of definition/implementation, and you need all three to be able to use a feature:
The feature must be part of the ACSL language.
It must be made available by the current Frama-C front-end. Not all features of the ACSL language are immediately implemented in the front-end.
The plug-in you intend to use must take advantage of it.
Another explanation of the same distinction is here.
I can't declare a ghost variable as in "//# ghost set someSet;".
In your case, it appears that the partially implemented feature is not so much sets (which seem implemented in the front-end after a quick look) but ghost code, which can currently only use C constructs and types.
Or maybe the Mac version (I downloaded the Intel binary version) is
outdated and I should compile the latest source code ?
You have the latest version at this time.
Related
Coming from an R background, and just started learning Julia, I wonder how's documentation in Julia, and if there are analogues to R's help pages and vignettes.
Furthermore, in R, one can document functions using roxygen comment blocks, is there also something similar in Julia?
I think it is best to understand how things work by example. I will comment on how DataFrames.jl is documented as this is a pretty standard approach:
Functions are documented using docstrings, here is an example of a docstring of function names; These docstrings are then discoverable interactively via help system (by pressing ?)
A standard way to generate a documentation for a package is to use Documenter.jl; by the way: the package has a great team of maintainers who are very helpful and responsive; here you have a link to the make.jl file that is executed to generate the documentation; note in particular the option doctest=true which makes sure that all code examples that are properly anoteted following Documenter.jl rules are producing an expected output
In order to set-up auto-generation of package documentation you need to set up CI integration on GitHub; again - there are many ways to do it; a standard one is to use GitHub Actions; here you have a link to the part of the ci.yml specification file that ensures that documentation is built as a part of CI; then in any PR, e.g. this one (I am giving a link to a currently open PR that is documentation related) you can see in the section reporting CI results that after running tests also documentation was generated. Here you can see how a documentation generated using this toolchain looks like (e.g. note that at the bottom you can switch the version of the package you want to read manual of dynamically which shows you that all here is really well integrated - not just a bunch of PDF or HTML files).
I hope this will help you to get started. I have pointed you to all essential pieces that are normally used by packages hosted on GitHub (i.e. this is not the only way to do it, but it is a standard way most commonly used).
To master all the details of the above you need to read the documentation in the Julia Manual and Documenter.jl carefully. Unfortunately writing a proper documentation is not easy (in any programming language). The good thing is that Julia has a really excellent toolchain that supports this process very well.
I am trying to use errExit function on CLion IDE but it seems gives this error.
"cant resolve errExit variable" . I cant find anything about it,which header to use? I simply use text book example and included all headers from there still nothing?
You are seeing these error messages, because errExit is not a standard API function.
The camelCaseNotation is a good indicator of this. As a rule of thumb, the standard bodies of POSIX, UNIX and BSD -- which define most of the standard utilities and functions present on conforming GNU/Linux systems today -- specify functions using underscore_notation.
My guess is that the authors of the books you follow provide a definition for that function for their readers to use. Try looking for it in an earlier chapter, in the index, or in the supplementary material. But you won't find it in the systems standard include files.
I'm stuck using the 4.0 version of lua which does not seem to support the os library. Is there a way to include this library into my project?
Or get another way to use the functionality contained within pertaining to date time calculations?
Preferably by using a *.lua file and not a *.c file since I don't have complete access to the code.
When I run the following line,
print(os.time{year=1970, month=1, day=1, hour=0})
I get an error stating:
attempt to index global 'os'(a nil value)
As #Colonel Thirty Two said it's not possible to use the os library. So the time() funciton is not available for me.
Adding to the (totally correct) currently accepted answer (that if "os" access was not allowed to you, you're generally done), there's some very slight chance the Original Programmer may have provided you with some alternative facilities to do your thing (fingers crossed). In a perfect world, those would be described in some kind of a User's Manual for your scripting environment. But if the manual was lost to time (or never existed in the first place), you might possibly try your luck at exploring any preloaded libraries by digging through the result of the globals() Basic Function. (At least I hope that's how it was done in 4.0 too.) That is, if the Original Programmer didn't block globals() for you too...
I'd like R to show me debug messages in english instead that in my locale (Italian). Having messages in italians makes it difficult to look on the internet for help on debugging. Not to mention that sometimes translations are sloppy at least.
How can revert R to use only the original version of messages and not to translate them?
thanks!
You want to set the "LANGUAGE" environment variable (see relevant documentation):
Sys.setenv(LANGUAGE='en')
To do this, though, you need to have message translations installed (which I believe are optional on at least some platforms).
When using the program slicer of Frama-C version Oxygen, I have the problem that the resulting slice uses undeclared variables.
I searched for existing postings to this topic before and found this:
http://bts.frama-c.com/print_bug_page.php?bug_id=806
There it is mentioned that the bug was fixed in the Nitrogen version of Frama-C. Maybe this change was not carried over to Oxygen? Like in the description of the existing posting it only happens for blocks with just one statement.
I cannot attach the example source code since it is from a customer project.
I have checked the exact steps described in the bug report you mention with Frama-C Oxygen (and csmith 2.0.0 for Csmith's runtime library), and everything works fine: it's very likely that you're experiencing another issue, but without the code, it's impossible to say more.