On FreeBSD 11.1 I am having problems building mariadb101-server. So as a last resort I thought I might grab the binary from the quarterly (kids, you should normally not mix ports with packages) repo, but there's no package for mariadb101-server:
http://pkg.freebsd.org/FreeBSD:11:amd64/quarterly/All/
Why is it not there?
You could try the latest:
http://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/
The mariadb101-server:
http://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/mariadb101-server-10.1.33.txz
The reasons for why is not listed in the quarterly seems to be because some critical vulnerabilities, you can read more about it here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219045
when I type ompi_info on my terminal, I get a huge output on my terminal buffer, a part of which looks like :
Package: Open MPI buildd#lgw01-57 Distribution
Open MPI: 1.10.2
Open MPI repo revision: v1.10.1-145-g799148f
Open MPI release date: Jan 21, 2016
Open RTE: 1.10.2
Open RTE repo revision: v1.10.1-145-g799148f
Open RTE release date: Jan 21, 2016
OPAL: 1.10.2
OPAL repo revision: v1.10.1-145-g799148f
OPAL release date: Jan 21, 2016
MPI API: 3.0.0
Ident string: 1.10.2
Prefix: /usr
Configured architecture: x86_64-pc-linux-gnu
Configure host: lgw01-57
Configured by: buildd
Ignoring the info on release dates, I am curious specifically about the meaning of second line: Open MPI : 1.10.2 and line number twelve: MPI API : 3.0.0 . Does it mean the new functions from Open MPI version 3.0.0 available on the MPI version 1.10.2 ?
Open MPI is an implementation (e.g. code) of the MPI Standard (e.g. pdf document).
These are two distinct things that have their own and independent versions.
Answering my own question, it seems yes, the stable version of OpenMPI 1.10 supports most of the new features introduced in MPI 3 . This page of OpenMPI-1.10.1 shows the list of all MPI API's available which includes the API for one sided communication, which was introduced in MPI version 2.0, and features of MPI 3.0 like non-blocking collective operations like MPI_Ibcast and matching probes like MPI_Mprobe and MPI_Mrecv.
Although this list also doesn't contain the MPI_T tool interface and many other features which is available in the current stable release of openMPI-3.0 .
When I submit my package to CRAN, it does not pass the automatic incoming checks with a following warning:
* checking whether package 'EpiILM' can be installed ... WARNING
Found the following significant warnings:
Warning: GNU Extension: Different type kinds at (1)
and corresponding log file says
Epimcmc.f95:440.25:
psi= min(1.0,exp(ratio))
1
Warning: GNU Extension: Different type kinds at (1)
When I tested my package using R CMD CHECK and R CMD CHECK --as-cran, both result no warnings or notes. I am using an R version 3.3.2 (2016-10-31) -- "Sincere Pumpkin Patch" on my MacOS and codes are written in Fortran 95.
Any suggestions?
Your code is too short to diagnose exactly, but it can be probably inferred safely what the not-shown part of the code is.
Your ratio is of different kind than default one, probably `double precision.
But 1.0 is the default kind (aka. single precision).
Mixing different kinds in min() is not allowed in Fortran, but you do this in:
min(1.0,exp(ratio))
To fix the problem, use literals of the same kind as ratio is. So if it is a double precision, you can use:
min(1.0d0, exp(ratio))
and if it is some real(rk) you can use
min(1.0_rk, exp(ratio))
The real(.., kind=rk) function can also be used.
The warning says that the GNU Fortran compiler recognizes it is not allowed in Fortran, but allows it as a non-standard extension. Whether using this extension is allowed by the CRAN coding standards is a different question. Probably no, if it got rejected.
I would like to produce a log-file which keeps track of all commands (stdin), results (stdout) and errors/warnings/messages (stderr) in the R console.
I am aware that there are a lot of logging-packages and I tried several like TeachingDemos (seems to ignore stderr completely) or R2HTML (seems to ignore messages), however, none of them seems to include everything from stderr.
Only knitr and markdown seem to be able to include everything into a single file. But using this workaround, I have to write R-scripts and I cannot freely write commands in the console. Furthermore, I cannot include the knitr or markdown command in the same R-script (which is of course a minor problem).
Here is an example:
library(TeachingDemos)
library(R2HTML)
library(TraMineR)
logdir <- "mylog.dir"
txtStart(file=paste(logdir,"test.txt", sep=""), commands=TRUE,
results=TRUE, append=FALSE)
HTMLStart(outdir = logdir, file = "test", echo=TRUE, HTMLframe=FALSE)
## Messages, warnings and errors
message("Print this message.")
warning("Beware.")
"a" + 1
geterrmessage()
## Some example application with the TraMiner package
## which uses messages frequently
data(mvad)
mvad.seq <- seqdef(mvad[, 17:86])
mvad.ham <- seqdist(mvad.seq, method="HAM")
txtStop()
HTMLStop()
If you are running R from a Unix/Linux/Mac/etc. terminal, you can do:
R | tee mydir/mylog.txt
On windows, you can run the script in
R CMD BATCH yourscript.R
and your result will appear in the same folder as yourscript.out
On unices, I've often used the following code idiom with bash:
Some Command 2>&1 | tee NameOfOutputFile.txt
The "2>&1" says to take stderr and redirect it to stdout, which then gets piped to "tee". I will be experimenting with this and other ways of logging an R session.
Another unix trick is the "script" command, which starts a subshell whose I/O (basically everything you type and see in return) is logged to the specified file. And then exit the shell to end the script. Again, subject to experimentation. Since "sink" is native to R, I'll be trying that first.
By the way, I picked these tricks up using solaris, but they work the same running Cygwin, the unix emulator on Windows. Long time ago, I found that my Cygwin images were more up-to-date than the institutional installations of Solaris because the administrators had much more responsibility than just keeping the Solaris up-to-date. Mind you, the institutional machines were more powerful, so even though Cygwin was way more convenient, my personal machine simply didn't fill the need.
AFTERNOTE:
I took example code from page 99 of Shumway's Time Series Analysis and Its Applications With R examples. Here are the contents of a test file palette.R:
r
plot(gnp)
acf2(gnp, 50)
gnpgr = diff(log(gnp)) # growth rate
plot(gnpgr)
acf2(gnpgr, 24)
sarima(gnpgr, 1, 0, 0) # AR(1)
sarima(gnpgr, 0, 0, 2) # MA(2)
ARMAtoMA(ar=.35, ma=0, 10) # prints psi-weights
quit("no")
exit
I invoked it using:
script < palette.R
It captures the commands from palette.R and the corresponding output. So, seems usable for batch mode. For interactive mode, I'm going to go with my original plan and use sink.
I had a similar problem and in my case, I was unable to redirect truly all the output into my log file, as it was dependent on R running in interactive mode.
Specifically, in my log file, I wanted to be able to keep track of the progress bar generated by the rjags::update() function which, however, requires interactive mode:
The progress bar is suppressed if progress.bar is "none" or NULL, if
the update is less than 100 iterations, or if R is not running
interactively.
Therefore, I needed to trick R into thinking that it was running interactively, while it was in fact run from a bash script (interactive_R.sh, below) using here document:
interactive_R.sh
#!/bin/bash
R --interactive << EOT
# R code starts here
print(interactive())
quit("no")
# R code ends here
EOT
(Sidenote: Make sure to avoid the $ character in your R code, as this would not be processed correctly - for example, retrieve a column from a data.frame() by using df[["X1"]] instead of df$X1.)
Then you can simply run this script and send its contents into a log file using the bash command below:
$ ./interactive_R.sh > outputFile.log 2>&1
Your log file will then look as follows:
outputFile.log
R version 4.0.2 (2020-06-22) -- "Taking Off Again"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-conda_cos6-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
>
> # R code starts here
> print(interactive())
[1] TRUE
> quit("no")
I'm trying to apply frama-c/jessie on a module of a proprietary safety critical system from our customer. The function under analysis is pretty big (image 700 uncommented lines count) with a lot of conditional statements as well as complex (&&, ||, etc).
I got this error message when I ran it on Ubuntu VM 64 bit machine. It appears Error 137 is related to memory size, etc. But I'm not quite sure.
Any suggestion for how to approach this error is greatly appreciated.
[
formal_verification]$ frama-c -jessie test.c
[kernel] preprocessing with "gcc -C -E -I. -dD test.c"
[jessie] Starting Jessie translation
[jessie] Producing Jessie files in subdir test.jessie
[jessie] File test.jessie/test.jc written.
[jessie] File test.jessie/test.cloc written.
[jessie] Calling Jessie tool in subdir tests.jessie
Generating Why function testFun
[jessie] Calling VCs generator.
gwhy-bin [...] why/test.why
Computation of VCs...
Killed
make: *** [test.stat] Error 137
with a lot of conditional statements as well as complex (&&, ||, etc).
You should use the so-called “fast WP” option when analyzing functions with lots of nested conditionals. Otherwise, the target does not even need to be very large to cause a blowup.
It happens to be the example in Jessie's manual for passing options to Why (it is really a Why option):
-jessie-why-opt=<s>
give an option to Why (e.g., -fast-wp)
You would therefore use -jessie-why-opt=-fast-wp.