- NEMO, ZENO and falcON have too many small differences
  falcON uses Position/Velocity
  NEMO uses PhaseSpace

- a git branch is dealing with a better definition of		
  images, basically doing FORDEF instead of CDEF.
  CDEF has always been a bad idea... given that most our
  image work is via FITS
  This branch is now very old converted from CVS.

- making galaxy models is a special art which deserves a special
  section:

    mkdisk
    mkexpdisk
    magalie
    mkkd95	(GalactICS)


  Made-to-measure modelling of observed galaxy dynamics
  Jo Bovy, Daisuke Kawata, Jason A. S. Hunt

   PRIMAL  (Hunt et al)

   NMAGIC

   Syer & Tremaine  2009
   https://ui.adsabs.harvard.edu/abs/1996MNRAS.282..223S/abstract

MacOSX problems: (a special macosx.html web page dedicated to this)
    See:     http://bima.astro.umd.edu/nemo/macosx.html
  - configure leaves -lcrt.o etc. in, so they need manual removal
    from makedefs and NEMORC.gen before continuing on
    Also check http://www.astro.gla.ac.uk/users/norman/note/2004/restFP/
    ** most of this should be solved with the jan-2013 changes to
       configure. I get a clean install on mac 10.8, 

  - see also:
    http://www.fortran-2000.com/ArnaudRecipes/sharedlib.html

  - src/nbody/evolve/aarseth/nbody0/Makefile
	need to activate F77LIBS to include -lcc_dynamic (10.3 ?)
        but sometimes you to take it out again...... (10.4 ?)

GCC4 problems: (as tested on FC3/FC4)
  - pgplot: needs a gfortran_gcc4.conf file for now
	also:  no more -fno-backslash
	also:  %VAL() does not seem to be supported anymore ???
	also:  some formatted reading that spans multi lines BAD (pgpack.f)
  - no more -fno-globals for fortran
  - no more -fwritable-strings in C
  - -fno-globals
  - g95 vs. gfortran, use the new m4 macros
  - the linker is now more conservative, removing references to code
    that is never used. get_atable and sqr come out in some tests
    as missing...
    The flag
		-fno-unit-at-a-time
    might work for a little bit.
  - see also:
	http://www.kegel.com/gcc/gcc4.html
        http://womble.decadentplace.org.uk/c++/syntax-errors.html

-------------------------------------------------------------------------------

general things for 3.2.x
  - make sure cfitsio stuff is ok in configure (THIS IS BROKEN NOW)
  - the change in get_atable() should mean routines need to work
    on buffered table read better
  - ccdmath WCS is broken
  - fix installation if no fortran is available
	(fmath in potential not needed)
	(some potential/data not needed)
  - intel linker problems (use different technique to force loading?)
	e.g. intel says to use
	export GXX_ROOT=/usr/i686-pc-linux-gnu/gcc-bin/3.3/"
	if compilers are in non-standard locations, and
	export LC_ALL=C
	if you're working on a non-english linux OS
  - use some kind of global MAXBODY where we often use different values
	**mostly done**

 -  falcON/utils install uses some linux dialect:

   1) mkdir
	mkdir --parents --mode=755 ...
      on the mac this should be
	mkdir -p -m 755 ....
   2) linking:  -rdynamic, -shared, -rpath  are not understood
	g++ .... -shared -o XXX.so

	Walter uses:
	-shared -o lib/libWDutils.so -march=i386 -mpreferred-stack-boundary=4
	OSX/intel can use:


	gcc -c -fno-common testlib.c
	NO:  gcc -dylib -flat_namespace -undefined suppress -o libtestlib.dylib testlib.o
	YES: gcc -dynamiclib -o libtest.dylib -dylib t.o

   on some (linux) distributions you may need to have to edit the
	utils/make.gcc file (remove -march=native from OPTFLAGS :=), and edit
	falcON/makedefs (remove -Wtype-limits from WARNINGS :=)
	

 - a few snapshot I/O programs still use the old I/O, hence Position/Velocity data is 
   now difficult to make global.


--------------------------------------------------------------------------------

some other help on configure: [1998]
	http://www.airs.com/ian/configure/
	
code & line coverage: (gcov, lcov)
  http://ltp.sourceforge.net/coverage/lcov.php
  
- use cfortran?  cfitsio also uses it. [1998]

- unsio (and possibly a few more modules) won't link if e.g. pgplot was enabled
  with png. are some interfaces not cleanly separated?  maybe via yapp_pgplot ?

- if the code has to be C++ friendly, i.e. the nemo_main() be compiled
  by c++, but the rest with CC,  all extern's must be wrapped in

  #if defined(__cplusplus)
  extern "C" {
  #endif
  ...
  #if defined(__cplusplus)
  }
  #endif

- getparam:  an option to produce an iraf .par file?

- getparam:  finish the outkeys= stuff

- zeno: some more Zeno compatibility

- overal design:
  separation of functionality and data format. E.g. to compute the 
  statistics of a variable in either a table, a snapshot or an image
  should have the same set of keywords that control the statistics.
  Yet accessing the data is different. This is done rather sloppy
  and slightly different in different places.

- fortran-to-C
   some fortran compilers need -nofor_main to prevent main getting
   linked in from the fortran library
   
   some linkers want to link with gcc, not g77 or vice versa? This
   may require a configure macro in the makefiles

- still various problems in -DSINGLEPREC mode:

	- nemo_io
	- rotcur/rotcurshape: cube1/cube1.sig appears to create some NaN pixels
	- mkommod has problems with out of bounds intervals
	- hackdens doesn't compile

- configure should use more consistent use of the
	--with-xxx-yyy=DIR
  where xxx is any of e.g. x11,tk,tcl,,.... libaries
  and yyy is either dir    if it specifies -I DIR/ionclude -L DIR/lib
	        include    if it specifies -I DIR
		    lib    if it specifies -L DIR

- alternatives to autoconf?  
	Pre Make Kit  = http://pmk.sourceforge.net/
	cmake (KDE uses it)
  also check the Autoconf Macro Archive: http://autoconf-archive.cryp.to/
 
- Testfile's:    also needs a program to be added to the local Makefile,
	as well as in the list of programs to be installed...
	that's non-intuitive

- man pages vs. doxygen; especially the introduction of C++ is showing 
  the aging of man pages. should we switch to doxygen?


Linking:
--------

Linking can be done with ld, or with the compiler. But which compiler?
Should it be the one main() is written in, i.e. gcc for C programs,
and gfortran/g77 for PROGRAM's ?
The FLIBS macro from autoconf defines a bunch of -L..... -lg2c (-lgfortran)
The example where this linking got problematic is the mkkd95 tools.
    mknemo  mkkd95
shows the complexity in failure and success.



Intel compiler 9.0 (sep 2005):
------------------------------

- some warnings in the Tk drivers

- a number of these linking problems (e.g. cpgdemo's, but also libpgplot.so)
  show up when multiple .o files are combined in an executable.

IPO link: can not find "("
icc: error: problem during multi-file optimization compilation (code 1)
make[1]: [libpgplot.so] Error 1 (ignored)


=

building shared vs. static:

gfortran -shared -O2 *.f -o libfoo.so -fPIC

gfortran -O2 -c *.f; ar cr libfoo.a *.o

optimize with:   -mtune=pentium4 or -ffast-math

DYLD_LIBRARY_PATH (osx) vs. -rpath-link (linux) vs. LD_LIBRARY_PATH


==  

on mac a few minor issues w/ gyrfalcON:

	YES: gcc -dynamiclib -o libtest.dylib -dylib t.o


$(LIB)lib$(LIBNAME).so: $(falcON_objs)
                        $(CXX) $^ -shared -o $@

becomes:


bad is:

g++ lib/basic.o lib/body.o lib/tree.o lib/gravity.o lib/kernel.o lib/io.o lib/partner.o lib/nbody.o lib/forcesC.o lib/tools.o lib/sample.o lib/manip.o lib/profile.o lib/bodyfunc.o lib/neighbours.o lib/PotExp.o -dynamiclib -o lib/libfalcON.dylib


and in utils/Makefile

$(LIB)libWDutils.so:    $(LIB)libWDutils.dylib

$(LIB)libWDutils.dylib: $(WDutils_objs)
                        $(CXX) $^ -dynamiclib -o $@ $(CPUFLAGS)


	 few more isnan() and isinf()  fixes  wiht std::

- old style diff and patch
    diff  file.old  file.new > file.patch
    patch file.old -i file.patch -o file.new
    
diff brent.for brent_dbl.f > test/brent.patch
cd test
cp ../brent.for .
patch brent.for -i brent.patch -o brent_dbl.f

diff brent.for ..
diff brent_dbl.f ..


git tricks
----------

0) commands beginners should know

   git clone URL                    # get a new repo from URL
   git pull                         # update the repo
   git add FILE                     # add a new FILE
   git commit FILE                  # commit the FILE 
   git push                         # push the commit's

1) working with tags

   git tag --list                   # see what tags you have
   git tag nemo_4_3_2               # make a new tag (locally)
   git tag -d nemo_4_3_2            # delete that tag
   git push origin nemo_4_3_2       # push it out to the world 
   git checkout nemo_4_3_2          # switch to a tag
   git checkout master              # revert back

   todo:  see if "git push --tags"  also works

2) ? can you see what will be pushed when you "git push"
   since you may have done a whole bunch of "git commit"
   It would say something like
      "Your branch is ahead of 'origin/master' by 8 commits"

   git diff --stat --cached origin/master


3) if you accidentally edited a FILE and want to "undo" it,
   i.e. revert back to the original FILE:

   git checkout FILE

   this will silently overwrite your modified FILE with the
   original version!!!

 
4) working with another remote upstream

   Let say you work off a fork, and cloned that as you private workspace.
   The original NEMO would be the upstream master:

   git remote                                                # see which ones you have
   git remote add upstream https://github.com/teuben/nemo    # add this one-time

   git branch                                                # check what branch you are on
   git checkout master                                       # ensure on your master
   git fetch upstream                                        # fetch the upstream
   git merge upstream/master                                 # merge in 
   git status                                                # should be no new things
   git push                                                  # push it to your origin

5) When pgplot changed their URL:

   git remote -v

   git remote rename origin teuben
   git remote add origin https://github.com/astroumd/pgplot

==

ANSI-C:

https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Standards.html#C-Language

NEMO was developed in 1986/7, using the SunOSx cc compiler. This was
several years before ANSI-C was ratified. The famous K&R V1 book was our
bible. Although slowly migrated,there are still many snippets of code
that violate the standard. Sometimes you will find this version
referred to as the K&R version of C.

C89:
gcc can compile with this using:   -ansi, -std=c89 or -std=iso9899:1990
and if you add -pedantic it will display all the ansi violations

C99:
The next major revision was C99 ,  -std=c99 or -std=iso9899:1999.
https://gcc.gnu.org/c99status.html

C11:
-std=c11 or -std=iso9899:2011.

C2X:
What will be in the future. Here are some hints:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2494.pdf


In 2020 we started to really go over the code

c/clang
  inline
  VLA?s
  

Bad habits that need to change:
- real ->  float or double
- int      is there code that assumes it's 32bit?
- proc,rproc,iproc
- bool     we use TRUE and FALSE a lot.

1.6.1.1    arrays are not pointers