How is `ghc Main.hs` different from `ghc --make Main.hs`? - ghc

I see the documentation on ghc's --make, however I do not understand how running ghc with --make is any different from running it without that option.
To investigate, I created these modules Main and Dependency:
module Main where
import Dependency ( myNumber )
main :: IO ()
main = do
print "running program"
print myNumber
print "terminating program"
and
module Dependency where
myNumber :: Integer
myNumber = 42
From the directory containing these modules, I ran both ghc Main.hs and ghc --make Main.hs. Though the two commands wrote different messages while running, both worked successfully and produced the same output files.
$ ghc Main.hs
[1 of 2] Compiling Dependency ( Dependency.hs, Dependency.o )
[2 of 2] Compiling Main ( Main.hs, Main.o )
Linking Main ...
$ ls
Dependency.hi Dependency.hs Dependency.o Main Main.hi Main.hs Main.o
and
$ ghc --make Main.hs
$ ls
Dependency.hi Dependency.hs Dependency.o Main Main.hi Main.hs Main.o
What, if anything, does the --make option do that's different from what ghc does without it?

Related

Installing from Archive of Formal Proofs

I'm trying to install Grothendieck_Schemes from
https://www.isa-afp.org/entries/Grothendieck_Schemes.html#
I downloaded the tar and uncompressed it. The contents are
$ ls -l
Comm_Ring.thy
Group_Extras.thy
ROOT
Scheme.thy
Set_Extras.thy
Topological_Space.thy
document/
root.bib
root.tex
Then I run
$ isabelle components -u ./Downloads/Grothendieck_Schemes/
Added component "/home/username/Downloads/Grothendieck_Schemes"
but when I start Isabelle I get error
C:\Users\Aleksander\.isabelle\Isabelle2022\jedit\jars\isabelle_jedit_main.jar:
Cannot start:
*** Bad imports session "Jacobson_Basic_Algebra" for "Grothendieck_Schemes" (line 3 of "/home/username/Downloads/Grothendieck_Schemes/ROOT")
So I suppose I should install the dependency "Jacobson_Basic_Algebra"? But there is no such package on AFP. I'm thinking that maybe I should have removed the ROOT file. It's contents are
chapter AFP
session "Grothendieck_Schemes" (AFP) = HOL +
options [timeout = 600]
sessions
"Jacobson_Basic_Algebra"
theories
Scheme
document_files
"root.tex"
"root.bib"
I tried running this instead but it fails
$ isabelle components -u ./Downloads/Grothendieck_Schemes/*.thy
*** Bad component directory: "/home/username/Downloads/Grothendieck_Schemes/Comm_Ring.thy"
How do I install these packages properly?

Difficulty making Healpix compatible with GDL

PROBLEM:
I am having difficulty running Healpix-IDL routines with GDL with the current version of Healpix, Healpix_3.20.
The easiest thing to do would be to follow user gilo in this post:
http://sourceforge.net/p/gnudatalanguage/discussion/338692/thread/6546b9ad/?limit=25#324d
All Healpix IDL routines are downloaded in ~/user/downloads/Healpix_3.20/src/idl
Then, use !PATH i.e.:
GDL> !PATH = expand_path('+/user/myname/downloads/HEALPix_3.20/')+':'+!PATH
and after that you have access to all healpix procedures within gdl
That doesn't work for me. I try the command hidl and hididle in the Terminal (I'm using Mac OS X Yosemite, 10.10.5):
GDL> hidl
% Procedure not found: HIDL
% Execution halted at: $MAIN$
Any other solutions?
POSSIBLE SOLUTIONS:
In the installation procedures install.pdf, Section 7.6 hidl usage describes that hidl is sometimes not recognized. A fix is setting the environment variable IDL STARTUP to be equal to the HEALPix startup file HEALPix startup including the directory path to the file, i.e. use
setenv IDL_STARTUP /disk1/user1/HEALPix_2.15a/src/idl/HEALPix_startup for C shell, csh
export IDL_STARTUP="+/disk1/user1/HEALPix_2.15a/src/idl/HEALPix_startup" for s, sh, bash
For my routines, this should be
export IDL_STARTUP="+/usr/downloads/HEALPix_3.20/src/idl/HEALPix_startup"
on bash Terminal
(Recall syntax:
export key=value is sh, ksh, bash
setenv key value is csh)
This doesn't work for me. After executing the command, and entering gdl, I get:
% Error opening startup file: /user/myname/downloads/HEALPix_3.20/src/idl/HEALPix_startup
Following Section 7.8 Using GDL instead of IDL, I try
$ export IDL_TMPDIR=/tmp
$ gdl
This doesn't work either.
Following Using HEALPix IDL together with other IDL libraries in the IDL routines manual, idl.pdf, I try
export IDL_PATH="+/user/myname/downloads/HEALPix_3.20/src/idl/:+/opt/local/share/gnudatalanguage/lib:<IDL_DEFAULT>"
export IDL_STARTUP="+/user/myname/downloads/HEALPix_3.20/src/idl/HEALPix_startup"gdl`
output error:
% Error opening startup file: /user/myname/downloads/HEALPix_3.20/src/idl/HEALPix_startup.
I try
export IDL_PATH="+/opt/local/share/gnudatalanguage/lib:<IDL_DEFAULT>"
hidl
output error:
-bash: hidl: command not found
Nothing works.
BACKGROUND:
Healpix has the installation procedures here, at source forge.net: healpix.sourceforge.net/pdf/install.pdf
and the IDL routines here: healpix.sourceforge.net/pdf/idl.pdf
The sourcecode is here: sourceforge.net/projects/healpix/
In order to install Healpix, you use ./configure and then make. (See install.pdf, section 4)
Healpix IDL routines are downloaded in /user/myname/downloads/HEALPix_3.20/
GDL routines are located in /opt/local/share/gnudatalanguage/lib/
hidl is an alias to start IDL with the Healpix startup file and path. Type it on the system command line, not the IDL command line. You must run through their configure system to define hidl.
In subdirectory ~/.healpix/3_20_Darwin there are two files, config and idl.sh.
The config is
# configuration for Healpix 3.20
HEALPIX=/Users/myname/downloads/Healpix_3.20 ; export HEALPIX
HPX_CONF_DIR=/Users/myname/.healpix/3_20_Darwin
if [ -r ${HPX_CONF_DIR}/idl.sh ] ; then . ${HPX_CONF_DIR}/idl.sh ; fi
if [ -r ${HPX_CONF_DIR}/f90.sh ] ; then . ${HPX_CONF_DIR}/f90.sh ; fi
if [ -r ${HPX_CONF_DIR}/cpp.sh ] ; then . ${HPX_CONF_DIR}/cpp.sh ; fi
if [ -r ${HPX_CONF_DIR}/c.sh ] ; then . ${HPX_CONF_DIR}/c.sh ; fi
The idl.sh file is
# IDL configuration for HEALPix Fri MONTH DAY TIME EDT YEAR
# make sure IDL related variables are global
export IDL_PATH IDL_STARTUP
# back up original IDL config, or give default value
OIDL_PATH="${IDL_PATH-<IDL_DEFAULT>}"
OIDL_STARTUP="${IDL_STARTUP}"
# create Healpix IDL config, and return to original config after running Healpix-enhanced IDL
HIDL_PATH="+${HEALPIX}/src/idl:${OIDL_PATH}"
HIDL_STARTUP="${HEALPIX}/src/idl/HEALPix_startup"
alias hidl="IDL_PATH=\"${HIDL_PATH}\" ; IDL_STARTUP=${HIDL_STARTUP} ; idl ; IDL_PATH=\"${OIDL_PATH}\" ; IDL_STARTUP=${OIDL_STARTUP} "
alias hidlde="IDL_PATH=\"${HIDL_PATH}\" ; IDL_STARTUP=${HIDL_STARTUP} ; idlde ; IDL_PATH=\"${OIDL_PATH}\" ; IDL_STARTUP=${OIDL_STARTUP} "
So, if I manually set the paths in this idl.sh file and run config, i.e ~/.config. This should then allow one to use hidl in the command line to run the Healpix IDL routines, right?

Install GSLL on SBCL with Quicklisp

I am trying to install the GNU Scientific Library for Lisp (GSLL).
I saw there are answers to a similar question already, but I didn't find the connection to what is happening in my case.
Could anyone help to move on from here?
CL-USER> (lisp-implementation-type)
"SBCL"
CL-USER> (lisp-implementation-version)
"1.2.4.debian"
CL-USER> (ql:quickload "gsll")
; cc -m64 -I/lrde/home/alandi/quicklisp/dists/quicklisp/software/cffi_0.14.0/ -o /lrde/home/alandi/.cache/common-lisp/sbcl-1.2.4.debian-linux-x64/lrde/home/alandi/quicklisp/dists/quicklisp/software/cffi_0.14.0/libffi/libffi-unix /lrde/home/alandi/.cache/common-lisp/sbcl-1.2.4.debian-linux-x64/lrde/home/alandi/quicklisp/dists/quicklisp/software/cffi_0.14.0/libffi/libffi-unix.c
;
; compilation unit aborted
; caught 2 fatal ERROR conditions
To load "gsll":
Load 8 ASDF systems:
alexandria antik asdf-system-connections cffi-grovel
cffi-libffi metabang-bind osicat trivial-garbage
Install 1 Quicklisp gsll
release:
; Loading "gsll"
; cc -m64 -I/lrde/home/alandi/quicklisp/dists/quicklisp/software/cffi_0.14.0/ -o /lrde/home/alandi/.cache/common-lisp/sbcl-1.2.4.debian-linux-x64/lrde/home/alandi/quicklisp/dists/quicklisp/software/cffi_0.14.0/libffi/libffi-unix /lrde/home/alandi/.cache/common-lisp/sbcl-1.2.4.debian-linux-x64/lrde/home/alandi/quicklisp/dists/quicklisp/software/cffi_0.14.0/libffi/libffi-unix.c
;
; compilation unit aborted
; caught 2 fatal ERROR conditions
; Evaluation aborted on Component "gsll" not found.
I am on OS X, but maybe this helps you anyway. I could load the lib by (ql:quickload "gsll") but I had to make an adjustment:
The path to GSLs dynamic libraries is found by a shell call gsl-config --prefix.
For me this call returns /usr/local/Cellar/gsl/1.16 but my dynlibs are located in /usr/local/Cellar/gsl/1.16/lib. So I just had to make some adjustments to the pathnames in the file ~/quicklisp/dists/quicklisp/software/gsll-20140211-git/init/init.lisp.
Seach for (cffi:define-foreign-library libgslcblas ...) and (cffi:define-foreign-library libgsl ...) and adjust your paths there.
Maybe that helps.

alt-ergo does not run on windows via cygwin

I am trying to run a test file on frama-c with the alt-ergo prover. However,I am getting the followng error with alt-ergo. All the other frama-c checks are fine. I know that the issue is not with the test file.
------------------------------------------------------------
--- Alt-Ergo (stderr) :
------------------------------------------------------------
Fatal error: exception Sys_error("/tmp/wpf0dd65.dir/typed/test_post_2_Alt-Ergo.mlw: No such file or directory")
------------------------------------------------------------
[wp] [Alt-Ergo] Goal typed_test_post_2 : Failed
Error: Alt-Ergo exits with status [2]
I am on a windows machine and perform all of the installations via cygwin in administrator mode
I got frama-C Neon and installed it with ./configure & make & make-install, and the installation was successful ( all the frama-c checks pass in my test file)
I got the following version of alt-ergo Linux x86_64 binary: alt-ergo-0.95.2-x86_64 from http://alt-ergo.ocamlpro.com/download.php. I went with this version, since the frama-c docs ask for version 0.95.
I used the following instructions to install alt-ergo (https://www.lri.fr/~marche/MPRI-2-36-1/install.html)
Installation of Alt-ergo
The simplest way is to get the binary file of alt-ergo. Download the file called "Linux x86_64 binary" Then:
chmod +x alt-ergo-0.95.2-x86_64
sudo cp alt-ergo-0.95.2-x86_64 /usr/bin/alt-ergo
when calling which but frama-c and alt-ergo have a correct path
$ which frama-c
/usr/bin/frama-c
$ which alt-ergo
/usr/bin/alt-ergo
I also have why3 installed and it detects the ergo prover
$ why3 config --detect-provers
Found prover Alt-Ergo version 0.95.2, Ok.
1 provers detected and 0 provers detected with unsupported version
Save config to /home/username/.why3.conf
Edit
I created the following test.mlw with the online example
type 'a set
logic add : 'a , 'a set -> 'a set
logic mem : 'a , 'a set -> prop
axiom mem_add:
forall x, y : 'a. forall s : 'a set.
mem(x, add(y, s)) <->
(x = y or mem(x, s))
logic is1, is2 : int set
logic iss : int set set
goal g:
is1 = is2 ->
mem (is1, add (is2, iss))
running alt-ergo results in:
alt-ergo test.mlw
File "file.mlw", line 1, characters 1-26:Valid (0.0156) (0)
Any ideas?
The following treats the symptoms:
using the -wp-out flag with a windows path will solve the issue
for example
frama-c -wp -wp-print -wp-out c:/Users/userName/Desktop/tmp2 ../../cygdrive/c/Users/userName/Desktop/swap.c
Can you put the following example in a "file.mlw"
goal hello_world: 1+1 = 2
and then, try to execute your Windows and/or Cygwin binaries by providing "file.mlw" as input

How do I undefine %{dist} using rpmbuild to build SRPM?

I'm trying to work out my build process for RPMs.
When I produce source RPMs, it's including %{dist} in the file name. I would prefer that it only do that for the binary RPMs, since the source RPMs are not distribution specific.
The dist macro is defined in /etc/rpm/macros.dist. How would I undefine it while building source RPMs?
foo.spec:
Name: foo
Version: 0.1
Release: 1%{?dist}
# etc...
Build command:
$ rpmbuild -bs foo.spec
$ ls ../SRPMS
$ foo-0.1-1.el6.src.rpm
simple:
$ rpmbuild --undefine dist -bs foo.spec
I don't believe there's a way to conditionally check for what kind of package you are building, but you could try defining a macro at the command line only when building source packages. You would then conditionally checking for the macro at the top of your spec file:
$ rpmbuild -bs --define "mymacro 1" mypackage.spec
mypackage.spec:
%if 0%{?mymacro}
%undefine dist
%endif
To build a binary package, just omit the --define "mymacro 1":
$ rpmbuild -bb mypackage.spec

Resources