I just built installed from the Opam package manager, and am trying to learn how to use value analysis from the tutorial on the frama-c website. I'm currently unable to use the builtin.c file, it's not in my share folder and I cannot figure out how to use -val-builtin (if that's even appropriate).
Any ideas on how to get this going?
I installed the 20151002 release of Frama-c.
Thanks for the help!!
Frama-C "semi-builtins" such as Frama_C_interval no longer need an implementation to be analyzed by Value. Hence, most of builtin.c has been removed, and the rest has been inlined in other files. All mentions of builtin.c in the manual can be ignored, provided __fc_builtin.h is included instead. Similarly, builtin.h has been replaced by __fc_builtin.h. (But a warning is emitted to make the user aware of this fact.) We will update the manuals for Frama-C Aluminium to clarify this.
Regarding which version should be used, I strongly advise you to use Magnesium (20151002). There have been quite a few improvements through the years.
Related
the general questión would be how do I to use any library non-standar in Julia, e.g. libraries exported from C, specifically I downloaded the GNU Scientific Library from https://www.gnu.org/software/gsl/, according the Julia Manual I think it can be used, but I readed the INSTALL file from the GSL folder and I tried follow the steps, however I could not finish them because I did'nt understand some steps.
If anyone could give me some advice to use this library in Julia, I would appreciate it very much.
some details.
-OS: Windows10
-Julia version: 0.6
In the general case,
calling compiled code is done using ccall
For the case of GSL, for most operations you shouldn't be using GSL.
The (almost all) the functionality provided by GSL is well covered by the Julia standard library or by well maintained julia packages.
Mostly with implementation in pure julia.
Pure julia implementations will normally be basically as fast as the C/Fortran implementations.
Plus they will have other good features like working well with the optimiser,
and supporting custom types via multiple dispatch
For example supporting Dual numbers means that ForwardDiff.jl will just natively allow Auto differentiation to work with them.
For some code ducktyping will even let them work with things like TensorFlow..
As to how to install GSL, I think that is a seperate question from how to use GSL with julia.
Conviently though, if you are in a position you absolutely need to call GSL from julia,
there is already a julia package wrapping it. GSL.jl
And particularly conveniently, it will automatically download and install GSL for you when you run Pkg.add("GSL.jl"),
so you don't have to worry about installing it yourself.
If the package isn't working for you, raise an issue on their repo.
(Julia packages tend to be good like that, just installing all their dependencies so you don't have to fiddle around with things. I've been really impressed a few times when colleges have come to me saying "I love R library Foo but I can't using it on windows as I can't get the Fortran backend to work"; and I'll be like "Foo.jl does the same thing using the same fortran backend, also it automatically installs that backend, and does so in a way that just works even on windows.")
I'm looking to remove/modify the autocomplete-plus package that is bundled together with atom on install.
After a while of struggling and failing, I come to the wisdom of stack-overflow for how I can either:
Modify behaviour of autocomplete-plus
prevent it from loading in the first place (i.e. remove it from the bundle)
The default packages are stored inside an asar file (i.e. Atom.app/Contents/Resources/app.asar on macOS), so it's highly impractical to tamper with its contents, not to mention that your changes are getting lost with each Atom update.
Since you haven't given us a reason why you would want to do that, there is no ideal answer to your question. Generally speaking, I think there are better alternatives:
Disable the autocomplete-plus package and install your fork as you would install any other package. The Atom API offers ways to disable packages programmatically, if you want your fork to handle this.
Build your own custom version of Atom that suits your needs. The default packages are listed as packageDependencies in package.json.
You can go to edit->preferences in the main menu, then check under 'packages' in the left-hand menu, search for 'autocomplete-plus' and then click on 'disable.
I've been asked to customise the layout of the GNOME 3 desktop. Apparently the way to do that is by writing an "extension".
I've managed to do some of the things I wanted to do, but I feel utterly starved of information. I cannot find any useful documentation anywhere. I've wasted entire days of my life frantically googling every imaginable search term in a desperate attempt to find useful information.
The GNOME website has hundreds of extensions for download. These are not trivial 3-liners; they're sophisticated pieces of code. It defies belief that anybody could write these without documentation explaining how to do it.
Please, can somebody tell me where the actual documentation is? So far, the best I've managed to do is take apart existing extensions trying to track down the magic command that does the specific bit I'm interested in. (Not an easy task!)
Command names, object paths, example programs, anything would be helpful!
I have recently dug into it myself. The documentation is usually sparse or outdated. Here are some sources which helped me to get started (and through development):
Basic Stuff
Step-by-step tutorial (Gnome 3.4)
Unofficial documentation for the JavaScript bindings of many libraries
The sources of the gnome-shell's JavaScript bindings
Explanation of the St (Shell Toolkit) Ui-Toolkit components.
Some unofficial guidelines to get your extension on extensions.gnome.org
Since the documentation is nearly unavailable (or up to date), you'll need to do a lot of source-reading. I linked the gnome-shell sources above (the JavaScript part) which is a good start when diving into parts that are not covered by the In-official documentation (which is the most complete thing you'll find).
What's also particular helpful is checking extensions.gnome.org for extensions which do similar things to what you want to create, and look at their sources (most of them are open-source on GitHub or Bitbucket. You can also install them and find the sources under ~/.local/share/gnome-shell/extensions/).
When searching for something to use or more documentation on a particular function, you can also consult manuals for bindings in different languages (thought the parameters and return-values might not match).
Last but not least, here is some debugging advice:
LookingGlass is not particularly helpful. It only shows one line of an exception (the description) and only if they occur at startup time (when your extension is first started).
For full StackTraces and runtime-exceptions, consult the ~/.xsession-errors-file. It might be very long and bloated. I use this handy script to read it:
# Grabs the last session-errors from the current X11 session.
# This includes full Stack-Trace of gnome-shell-extension errors.
# See https://live.gnome.org/GnomeShell/Extensions/StepByStepTutorial#lookingGlass
tail -n100 ~/.cache/gdm/session.log | less
Note that since Gnome 3.6, if you are using gdm as display manager, the current session log is the file ~/.cache/gdm/session.log.
On some newer distros using systemd, you can get the error logs with:
journalctl -f /usr/bin/gnome-session
For debugging the prefs-part of your extension, you can launch the preferences by using the gnome-shell-extension-prefs-tool from a terminal, to see any exception-output on the console (you can also call the tool like gnome-shell-extension-prefs [uuid], to directly show your extensions preferences).
Since there is currently no real way of debugging with breakpoints (there is, but it's tricky), you can log on the console for quick checking, use the print()-function. You will see the output as mentioned above (either in the sessions-error file or on the terminal when starting gnome-shell-extension-prefs-tool).
Although it might be a little hard to get into it, the extension framework is quite powerful. Have fun!
I wrote a Blog-Post with somewhat greater detail, which can be found here: Making Gnome-Shell Extensions
An extensive list of references can be found on the Gnome Developer - API Reference page.
I used the following for my extension, but your use may vary:
GTK+ 3
GTK+ is the primary library used to construct user interfaces in GNOME applications. It provides user interface controls and signal callbacks to control user interfaces.
GDK 3
GDK is an intermediate layer which isolates GTK+ from the details of the windowing system.
Clutter
Clutter is a GObject based library for creating fast, visually rich, graphical user interfaces.
GObject Introspection
GObject Introspection is striving to provide a middleware layer between (GObject based) C libraries and language bindings.
Shell
Shell Reference Manual
St
St - Shell Toolkit - is the GNOME Shell's custom Clutter-based toolkit that defines useful actors. Some of these actors, such as StBoxLayout and StBin implement various layout options.
Icon Theme Specification
This freedesktop.org specification describes a common way to store icon themes.
NOTE: These last two are very helpful in finding visual element parameters!
PyGTK
PyGTK is GTK+ for Python. This reference contains a chapter for each Python PyGTK module (that corresponds to the underlying GTK+ library) containing the class descriptions.
PyGObject
PyGObject is a Python extension module that gives clean and consistent access to the entire GNOME software platform through the use of GObject Introspection. Specifically speaking, it is Python Bindings for GLib, GObject, GIO and GTK+.
This reference contains a chapter for each PyGObject module containing the class descriptions.
The documentation is on:
https://gjs.guide/extensions/
For the documentation of libraries:
https://gjs-docs.gnome.org/
More details on https://gjs.guide/extensions/overview/architecture.html
The other stuff you might want to check are
https://gitlab.gnome.org/GNOME/gnome-shell/blob/main/js/ui/popupMenu.js
https://gitlab.gnome.org/GNOME/gnome-shell/blob/main/js/ui/dialog.js
https://gitlab.gnome.org/GNOME/gnome-shell/blob/main/js/ui/modalDialog.js
https://gitlab.gnome.org/GNOME/gnome-shell/blob/main/js/ui/panelMenu.js
https://gitlab.gnome.org/GNOME/gnome-shell/tree/main/js
https://gitlab.gnome.org/GNOME/mutter
You can browse under js/ for more code to be reused.
You might also want to check https://gi.readthedocs.io/en/latest/index.html
Question:
I could not find anything under https://gjs-docs.gnome.org/ except some CSS and Javascript documentation ?!?!
Answer:
You have to first enable the docs to use them. Here, you will be mainly looking for:
clutter
meta
shell
st
Create a file like:
echo '{"docs":"clutter9~9_api/clutterx118~8_api/gobject20~2.66p/meta9~9_api/shell01~0.1_api/st10~1.0_api","hideIntro":"1"}' > devdocs.json
Import this file to https://gjs-docs.gnome.org/settings
Now you will be able to visit:
https://gjs-docs.gnome.org/shell01~0.1_api-global/
https://gjs-docs.gnome.org/shell01~0.1_api/
https://gjs-docs.gnome.org/meta9~9_api/
https://gjs-docs.gnome.org/st10~1.0_api/
https://gjs-docs.gnome.org/clutter9~9_api/
https://gjs-docs.gnome.org/clutter9~9_api-actor/
Warning: The version on the devdocs.json file is hardcoded. It will be outdated in no time, so you might want to check the version. The point is - you can not access docs until you enable them.
P.S. I know, this is a mess. This is how they did it.
I am taking over a project which involves upgrading to the latest version of Rcpp and thus I have to upgrade all the old style API calls (which is compatible with the CLassic version I believe). As there is no full API documentation, I am having to do this by trial and error and noting any "undefined reference" errors on linking and then looking through the vignettes/examples. The compile works fine but the errors arise on linking against \inst\libs\RLink.dll. I have manged to convert a lot of the code (mainly using Rcpp::List to extract and pack incoming and outgoing function parameters) but I simply cannot get equivalents for the following:
Rprintf or Rf_error and forward_exception_to_r.
R_NilValue
Rf_install
I am using Code::Blocks 10.05 IDE with RTools installed and Mingw64 referenced explicitly in the toolchain with the GNU GCC Compiler selected. I'd be grateful for any heads up. Thanks.
edit:
I do have #include and before that and (there was a series of errors that were occuring because I had included iostream before Rcpp, which was strange.
Can you please provide some concrete examples, maybe even on the rcpp-devel list? The porting approach works, I too have ported legacy code from the 'classic' Rcpp API, and so have others on the list.
But you do not have to port. The short vignette in the RcppClassic package has details on how to use it in case you want to maintain the old API.
While building Qt and Qt-based software on windows, it seems important to set MINGWDIR environment variable. But i'm not very pleased with doing something like 'voodoo magic', without knowing the reasons. Unfortunately, searching google reveals that it's a lot of tutorials and examples that sets MINGWDIR, but no documentation about this environment variable itself. Is it required by mingw32-make? Is it required by Qt? Is it not required at all? Maybe some guru knows WHAT exactly this environment variable is for and can point me to some mingw/gcc documentation or any article about it?
As you know, MinGW is a compiler. This enironment variable is used to point to the installation folder for it.
Does this article help ?