I propose a minor enhancement for IPosition::nonDegenerate(uInt
startingAxis = 0) in the future releases. It currently throws an exception if 
startingAxis is greater than or equal to the number of elements. I suggest 
to return unaltered IPosition in this case. Such behavior would be more
in line with the typical use case for this method (i.e. dropping
non-degenerate axes if they exist).

The initial idea was to have each package in casacore tagged by itself so
one could just release/install a subset of casacore. This doesn't seem to
be necessary as most people build everything.

Removing the batchbuild.py script  and package specific SConstructs
enhances maintainability and reduces complexity.
Dependencies are than handled by scons implicitly

To do:

 * Create top-level SConstruct
 * remove package level SConstruct and replace with SConscripts
 * remove intermediate package layer, e.g. images/images/Images would
become images/Images

There seem to be inconsistencies in handling explicitly given include dirs 
and/or handling of ones coming from XYZ_ROOT_DIR.

CFITSIO_ROOT_DIR=blah seems to translate into CFITSIO_INCLUDE_DIR
WCSLIB_ROOT_DIR ditto

FFTW3_ROOT_DIR doesn't show in the -I flags
FFTW3_INCLUDE_DIR doesn't show in the -I flags
FFTW3_INCLUDE_DIRS works.

Also there seems to be no way to tell the cmake's FindBLAS/LAPACK to use a 
custom directory e.g. BLAS_ROOT_DIR. Only explicit absolute path BLAS_LIBRARIES 
work.

I also fixed the CmakeInstructions where the wrong options were listed.

What steps will reproduce the problem?
1. install on a system which does not have aips++
2. ./batchbuild.py test
3.

What is the expected output? What do you see instead?

During the test phase, lots of things have been failing because the
measures stuff fails to find its data.


What version of the product are you using? On what operating system?

casacore-0.3.0patched.tar.bz2
SuSE 10.3
gcc 4.2.2


Please provide any additional information below.

Untarring the data directly into casacore-0.3.0 as instructed by the build
instructions page did not work.  Copying the data to the stage directory
did work, but did not seem like a good end solution.  So, Ger suggested
making a .casarc file.

On Wed, 4 Jun 2008, Ger van Diepen wrote:
> The Measures need to know where they can find their data files which for
AIPS++ was defined in aipsrc files to be found using AIPSPATH.
> For casacore we still use the same mechanism, but the aipsrc (or whatever
name you give it) to be used can also be defined via CASARCFILES.  It was
on my todo-list to add some comments about the casa resource files (the old
aipsrc) to the casacore pages, but hadn't done it yet.

Ok, I had not enabled any environment variables or hidden files, as
the instructions did not say to do so.  I now have made a ~/.casarc
file, and an environment variable CASARCFILES points to that.  I also
decided to make a CASACOREROOT directory to point to the end location
of the libraries and data areas.

> I have a .casarc in my home directory containing:
> 
> measures.DE200.directory: $HOME/measures_data/ephemerides
> measures.DE405.directory: $HOME/measures_data/ephemerides
> measures.line.directory: $HOME/measures_data/ephemerides
> measures.sources.directory: $HOME/measures_data/ephemerides
> measures.comet.directory: $HOME/measures_data/ephemerides
> measures.ierseop97.directory: $HOME/measures_data/geodetic
> measures.ierspredict.directory: $HOME/measures_data/geodetic
> measures.tai_utc.directory: $HOME/measures_data/geodetic
> measures.igrf.directory: $HOME/measures_data/geodetic
> measures.observatory.directory: $HOME/measures_data/geodetic

I copied this, replacing $HOME with $CASACOREROOT, and measures_data with
just data, and it failed to
work.  I them replaced $CASACOREROOT with the explicit path, and it
worked.  So, is $HOME special?  Yes, but not to casacore.  SCons
insists on blasting away your environment variables, so when you run
through the tests, you only have LD_LIBRARY_PATH, PATH, PWD, SHLVL,
and HOME defined.  So, your specific use of $HOME in your .casarc file
would work, whereas my $CASACOREROOT failed because scons doesn't like
that.

Ok, after placing CASACOREROOT into the casacore_assay batch program, the
test programs are able to find their data.  Hooray.  But I'm not sure how
to fix scons for others so that this is a final solution.

Note, I believe that this also means that things like AIPSROOT and AIPSPATH
will not be defined during the scons test phase either.

Hi all,

it is harro verkouter from JIVE here. I heard about casacore and decided to
give it try.

I followed the directions in the BuildingInstructins wikipage but the
compilation fails. I have tried both 32 and 64bit builds and both fail.
With the same error (below).

I am compiling on AMD64, Debian Sarge, gcc 3.4.4, scons 0.96.1 :

===> g++ version:

aips2mgr> g++ -v
Reading specs from /usr/lib/gcc/x86_64-linux/3.4.4/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4
--enable-shared --with-system-zlib --enable-nls --without-included-gettext
--program-suffix=-3.4 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt
--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm
--enable-java-awt=gtk --disable-werror x86_64-linux
Thread model: posix
gcc version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13sarge1)

===> scons version:
aips2mgr> scons -v
SCons by Steven Knight et al.:
        script: v0.96.1.D001, 2004/08/23 09:55:29, by knight on casablanca
        engine: v0.96.1.D001, 2004/08/23 09:55:29, by knight on casablanca
Copyright (c) 2001, 2002, 2003, 2004 The SCons Foundation


===> full machine info:
aips2mgr> uname -a
Linux beosrv 2.6.20.11 #1 SMP Mon May 21 13:03:35 CEST 2007 x86_64 GNU/Linux

===> The compilation commandline (for 32bit):

aips2mgr> python setup.py libtype=static
prefix=/data/00/casa-devel/casacore cfitsioroot=/apps/prod/local
wcsroot=/data/00/casa-devel/support  CPPFLAGS=-m32

===> And for 64bit it looked like:

aips2mgr> python setup.py libtype=static
prefix=/data/00/casa-devel/casacore cfitsioroot=/apps/prod/local
wcsroot=/data/00/casa-devel/support  CPPFLAGS=-DAIPS_64B


Anyway, both builds fail at:


g++ -m32 -O2 -I. -c -o build_linux_x86_64/opt/OS/Timer.o casa/OS/Timer.cc
In file included from /usr/include/sys/resource.h:5,
                 from ./casa/OS/Timer.h:53,
                 from casa/OS/Timer.cc:35:
/usr/include/i486-linux/sys/resource.h:88: error: declaration of `int
getrusage(__rusage_who_t, rusage*) throw ()' throws different exceptions
./casa/OS/Timer.h:51: error: than previous declaration `int
getrusage(__rusage_who_t, rusage*)'
scons: *** [build_linux_x86_64/opt/OS/Timer.o] Error 1
scons: building terminated because of errors.


Any help would be greatly appreciated!

cheers,

harro

r21022 added a check for defined(__MAC_10_6) at line 40 of casa/IO/TapeIO.cc.

__MAC_10_6 is defined in /usr/include/Availability.h, which isn't being 
included. It's therefore undefined, so the system proceeds to try to include 
<sys/mtio.h>, which doesn't exist on OS X 10.6, and therefore fails.

The attached patch fixes the issue.

Enabling debug mode for libstdc++ (-D_GLIBCXX_DEBUG) causes compilation of the 
LSQfit classes to fail. This is due to two simple problems in 
VectorSTLIterator.h:

1.  difference_type operator-(VectorSTLIterator<T> &x) const

x argument should be const

2.  iterator operator-(difference_type i) const

is implemented incorrectly, should be just like operator + two lines above it.

I attached a fixed version. 

What steps will reproduce the problem?
1. Scons 0.97
2. casacore from trunk
3. wcs lib/headers installed in /app/wcs/include and /app/wcs/lib
4. ./batchbuild.py wcslibdir=/app/wcs/lib wcsincdir=/app/wcs/include 
install

What is the expected output? What do you see instead?

When building module ''components'':
Building package: components
scons  prefix=/app/casacore/dev/casacore-20080902 wcslibdir=/app/wcs/lib 
wcsincdir=/app/wcs/include install casacoreroot=/app/casacore/dev/casacore-
20080902
scons: Reading SConscript files ...
Checking for C library gfortran... (cached) yes
Checking for C library m... (cached) yes
Checking for C library blas... (cached) yes
Checking for C library lapack... (cached) yes
Checking for C library cfitsio... (cached) yes
Checking for C library wcs... (cached) yes
scons: done reading SConscript files.
scons: Building targets ...
g++ -o build_linux_x86_64/opt/ComponentModels/SkyCompRep.o -c -fPIC -O2 -
I. -I/app/casacore/dev/casacore-20080902/include/casacore 
components/ComponentModels/SkyCompRep.cc
In file included from /app/casacore/dev/casacore-
20080902/include/casacore/coordinates/Coordinates/CoordinateSystem.h:34,
                 from components/ComponentModels/SkyCompRep.cc:42:
/app/casacore/dev/casacore-
20080902/include/casacore/coordinates/Coordinates/Coordinate.h:36:24: 
error: wcslib/wcs.h: No such file or directory

When I look in components/options.cfg:
casacoreroot = '/app/casacore/dev/casacore-20080902'
wcslibdir = '/app/wcs/lib'
CC = 'gcc'
CXX = 'g++'

so, there is no reference to wcsincdir. In the components/SConstruct file:

opts.Add(("wcsroot",
          "The root directory where wcs is installed", None))
opts.Add(("wcslibdir", "The wcs library location", None))

When I add:
opts.Add(("wcsincdir", "The wcs header file location", None))

It all works fine.

Same problem occurs in module ''images''

A closer look at the way in which certain observation-related information are 
transported within 
the data-formats supported by casacore yields, that there does not seem to 
exist a way in which 
to incorporate something as essential as a telescope position. The standard 
method encountered 
is, that an ObsInfo object is incorporated into a CoordinateSystem object, 
which then in turn is 
included into an image (though a coordinate system object can exist by its own 
right). The main 
limitation however is, that proper use of coordinates only can be made if the 
location of a 
telescope is registered as part of the measures data, from where the 
information is looked up. 
Closer inspection of the ObsInfo class yields that indeed only a string stored 
to encode 
information on the telescope:

[code]
casa::String telescope () const
casa::ObsInfo & setTelescope (const casa::String &telescope)
[/code]

On the other hand the instance on time, at which the observation took place can 
be stored as a 
Measure:

[code]
casa::MEpoch obsDate () const
casa::ObsInfo & setObsDate (const casa::MEpoch &obsDate)
[/code]

The question now is: why is there possiblity to also directly store the 
position of the telescope in 
question? Something like 

[code]
casa::ObsInfo & setTelescope (const casa::String &telescope, const 
casa::MPosition &position)
[/code]

surely would do the trick and would enable a) dealing with telescopes for which 
no position has 
been entered into the measures database and b) make the image files 
considerably more self-
contained. For the latter point consider the following: right now a simple 
operations such as 
regridding an image from AZEL coordinates onto J2000 coordinates will fail if 
a) the measures 
table with the telescope positions is not around and/or b) the telescope in 
question is not in the 
table. 

I would consider this as a serious flaw in the way metadata are handled and 
would strongly argue 
for the possibility to include the actual position information into ObsInfo; 
whether then it is filed 
in from the measures table or provided directly by the programmer/user is a 
secondary issue -- 
but at least this will help make the created images more transportable.

What steps will reproduce the problem?
1. ./batchbuild.py test
2.
3.

What is the expected output? What do you see instead?

I get

FAIL (execution failure): ./tDirectoryIterator

What version of the product are you using? On what operating system?

casacore-0.3.0patched.tar.bz2
SuSE 10.3
gcc 4.2.2


Please provide any additional information below.

tDirectoryIterator fails because the initial

AlwaysAssertExit (iter.name() == "a");

fails.  The Linux kernel was changed back around 2.4 so that the directory
information is hashed, and readdir in DirectoryIterator (such as
operator++()) returns the files in hash order, not in inode or creation
order.  This means that your alphabetical ordering of the expected return
sequence is wrong.

I don't know how much this affects the deep directory iterations you are
expecting to get with DirectoryIterator.  Does anything else within
casacore depend on getting back files in some specific order?

I have installed wcslib in /usr/local and /tmp. By default it picks up 
/usr/local. Specifying -DWCSLIB_ROOT_DIR=/tmp results in

<pre>
-- Found WCSLIB: /usr/local/lib/libwcs.a
...
-- WCS library? .......... = /usr/local/lib/libwcs.a;/usr/lib/libm.so
</pre>

while using WCSLIB_INCLUDE_DIR and WCSLIB_LIBRARY work as expected.

Currently the build system only looks in the default locations for
compilers and libraries/headers. Add scons command-line options to allow
for custom locations.

I run the build script as follows:
./batchbuild.py prefix=/opt/casacore-0.3.0 lapackroot=/opt/lapack
lapacklib=lapack_LINUX blasroot=/opt/blas/ static shared install

What is the expected output? What do you see instead?

Because I do not specify a custom fortran compiler, I expect it to detect
the system default compiler and just work. However, scons failes with 'A
custom fortran compiler also needs f2clib defined'.

What version of the product are you using? On what operating system?

casacore-0.3.0

Linux dop48 2.6.20-16-generic #2 SMP Tue Feb 12 05:41:34 UTC 2008 i686
GNU/Linux

g++ (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Please provide any additional information below.

If I explicitly remove the key "FORTRAN" from env in scimath/SConstruct it
works just fine. In casa/tools/utils.py on line 102 it will then autodetect
the correct fortran compiler and library. However, I do not understand
where the "FORTRAN" key comes from. Maybe scons adds this by default?

I get the following error:

Building package: tables
scons  enable_hdf5=false prefix=/usr/local wcsroot=/usr/local install
casacoreroot=/usr/local
scons: Reading SConscript files ...

scons: warning: The env.Copy() method is deprecated; use the
env.Clone() method                                      instead.
File "/usr/local/share/casacore/buildenv.py", line 3, in BuildEnv
AttributeError: SConsEnvironment instance has no attribute 'CXXFile':
 File "/home/timba/Desktop/casacore-0.3.0/tables/SConstruct", line 66:
   duplicate=0, exports=["buildenv", "installer"])
 File "/usr/lib/scons-1.0.1.d20081001/SCons/Script/SConscript.py", line 536:
   return apply(_SConscript, [self.fs,] + files, subst_kw)
 File "/usr/lib/scons-1.0.1.d20081001/SCons/Script/SConscript.py", line 259:
   exec _file_ in call_stack[-1].globals
 File "/home/timba/Desktop/casacore-0.3.0/tables/tables/SConscript", line 9:
   ff = myenv.CXXFile(File(f), CXXFILESUFFIX=".lcc")


The only version I've been able to build with is 0.97. This is pretty bad,
because scons 1.0.1 is designated a "stable" release, and they don't even
offer 0.97 for download anymore. 

What steps will reproduce the problem?
1. Compile program below with -DCASACORE_NO_AUTO_TEMPLATES - The program will 
not link
2. Compile program below with*out* -DCASACORE_NO_AUTO_TEMPLATES - The .tcc 
files (and therefore my short compiletest.cpp program) will not compile

What is the expected output? What do you see instead?

With -DCASACORE_NO_AUTO_TEMPLATES (link error):

g++ -g -Wall  -c -DCASACORE_NO_AUTO_TEMPLATES -L/usr/local/lib 
-I/usr/local/include/casacore -o compiletest.o compiletest.cpp
g++ -o compiletest -lcasa_tables -lcasa_scimath -lcasa_casa -lcasa_measures 
compiletest.o
Undefined symbols:
  "casa::MeasBase<casa::MVBaseline, casa::MeasRef<casa::MBaseline> >::set(casa::MVBaseline const&, casa::MeasRef<casa::MBaseline> const&)", referenced from:
      _main in compiletest.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [compiletest] Error 1

But without -DCASACORE_NO_AUTO_TEMPLATES, nothing using casacore will compile:

g++ -g -Wall  -c -L/usr/local/lib -I/usr/local/include/casacore -o 
compiletest.o compiletest.cpp
/usr/local/include/casacore/measures/Measures/MeasConvert.tcc: In member 
function 'void casa::MeasConvert<M>::init() [with M = casa::MPosition]':
/usr/local/include/casacore/measures/Measures/MeasConvert.tcc:96:   
instantiated from 'casa::MeasConvert<M>::MeasConvert(const M&, typename 
M::Types) [with M = casa::MPosition]'
compiletest.cpp:18:   instantiated from here
/usr/local/include/casacore/measures/Measures/MeasConvert.tcc:290: error: 
invalid use of incomplete type 'struct casa::MCPosition'
/usr/local/include/casacore/measures/Measures/MPosition.h:42: error: forward 
declaration of 'struct casa::MCPosition'
make: *** [compiletest.o] Error 1

Compilation exited abnormally with code 2 at Thu Sep  2 11:06:56


What version of the product are you using? On what operating system?
"/svn/trunk" tree build of casacore on OS X 10.6.4. All the libs and headers 
are installed in /usr/local/[lib, include]. Any help would be appreciated. 
Can't find any info on .tcc files, for example. Thanks.

This ticket should just track the progress. I know it is mostly done, but we 
can comment here.

This was uncovered using the slidingArrayMath functions, using MedianFunc, 
which calls median from Arrays/ArrayMath.tcc.
I noticed when running on a 1D Array, with the inPlace flag set to False (the 
default), that the input array was coming out sorted, which should not happen 
when inPlace=False

What steps will reproduce the problem?
1. The attached program tMedianSmooth.cc should reproduce a simple test case.
2. Take an array such as 
[0,1,2,3,4,0.01,1.01,2.01,3.01,4.01,0.02,1.02,2.02,3.02,4.02,...] (makes it 
easy to track what happens to individual elements.
3. Run a slidingArrayMath with MedianFunc on it, with boxsize=1 (ie. look at 
median of 3 elements at a time.

What is the expected output? What do you see instead?
Should get [0,1,2,3,3,1.01,2.01,3.01,3.01,1.02,2.02,3.02,...,0], but you don't. 
You instead get [0,1,2,3,3,3,3,3.01,4,4,4,4,...,0]


I'm also attaching a diff that patches the bug. The problem appears to lie in 
the median function, when it is setting up the location of the data to be 
sorted. If inPlace is false but there is contiguous storage, then the pointer 
used to sort the data remains pointing at the input.

I can download and compile casacore 1.0.0 with e.g.
{{{
scons --prefix=/home/twillis/casa_tests/casa_demo
}}}
That works fine - the whole system builds.

But when I do
{{{
scons install
}}}
Only the lib, bin and share stuff is copied to 
/home/twillis/casa_tests/casa_demo

The include header files are not copied over.

We need to build the casa notes. Use a scons latex target here. The install
dir should be the same as the API install dir so one can cross-reference.

What steps will reproduce the problem?
1. Try to use casacore to read any FITS file with BITPIX=8

What is the expected output? What do you see instead?

I would expect the library to load FITS files with any of the allowed 5 BITPIX 
values. Instead it only seems to work on 4/5...

Please provide any additional information below.

Currently Cube only has xyPlane. For various purposes, it would be helpful
to have xzPlane and yzPlane.

Thanks,

Tim

On Unix based system it is normal to include version numbers in your library 
naming. Casacore doesn't use versioning of libraries at the moment.

for more info see for example:

http://www.ibm.com/developerworks/linux/library/l-shlibs/index.html

Casacore trunk (and presumably other versions) aren't buildable with GCC 4.6: 
see the log below. Building with GCC 4.5 is fine.

The relevant change from the GCC release notes 
(http://gcc.gnu.org/gcc-4.6/changes.html) is "Most libstdc++ standard headers 
have been changed to no longer include the cstddef header as an implementation 
detail. Code that relied on that header being included as side-effect of 
including other standard headers will need to include cstddef explicitly."

The attached short patch gets things working for me.



$ g++-4.6 --version
g++-4.6 (Debian 4.6.1-4) 4.6.1
[...]

$ scons --with=cxx=g++4.6
[jds@crash casacore]$ scons --with-cxx=g++-4.6
scons: Reading SConscript files ...
Checking for C library dl... yes
Checking for C library gfortran... yes
Checking for C library blas... yes
Checking for C library lapack... yes
Checking for C library cfitsio... yes
Checking for C library wcs... yes

scons: warning: The build_dir keyword has been deprecated; use the variant_dir 
keyword instead.
File "/home/jds/Software/casacore/SConstruct", line 191, in <module>
scons: done reading SConscript files.
scons: Building targets ...
g++-4.6 -o build_linux_x86_64/opt/casa/aips.o -c -fPIC -DHAVE_DLOPEN -W -Wall 
-Woverloaded-virtual -O2 -I. casa/aips.cc
g++-4.6 -o build_linux_x86_64/opt/casa/version.o -c -fPIC -DHAVE_DLOPEN -W 
-Wall -Woverloaded-virtual -O2 -I. casa/version.cc
g++-4.6 -o build_linux_x86_64/opt/casa/Arrays/Array2.o -c -fPIC -DHAVE_DLOPEN 
-W -Wall -Woverloaded-virtual -O2 -I. casa/Arrays/Array2.cc
In file included from ./casa/Arrays/ArrayBase.h:34:0,
                 from ./casa/Arrays/Array.h:32,
                 from casa/Arrays/Array2.cc:28:
./casa/Arrays/IPosition.h:358:13: error: 'ptrdiff_t' does not name a type
In file included from ./casa/Arrays/Array.h:33:0,
                 from casa/Arrays/Array2.cc:28:
./casa/Containers/Block.h:310:11: error: 'ptrdiff_t' does not name a type
In file included from casa/Arrays/Array2.cc:28:0:
./casa/Arrays/Array.h:593:15: error: 'ptrdiff_t' does not name a type
./casa/Arrays/Array.h:631:15: error: 'ptrdiff_t' does not name a type
scons: *** [build_linux_x86_64/opt/casa/Arrays/Array2.o] Error 1
scons: building terminated because of errors.

When I try to build eg casarest against the current casacore trunk (r21201), I 
see eg:

   In file included from /opt/archive/2012-03-21-03-30/casacore/include/casacore/images/Images/ImageMoments.tcc:64,
                    from /opt/archive/2012-03-21-03-30/casacore/include/casacore/images/Images/ImageMoments.h:391,
                    from /opt/archive/2012-03-21-03-30/casacore/include/casacore/images/Images/MomentCalculator.tcc:39,
                    from /opt/archive/2012-03-21-03-30/casacore/include/casacore/images/Images/MomentCalculator.h:1171,
                    from /var/scratch/casarest/msvis/MSVis/MSMoments.h:41,
                    from /var/scratch/casarest/msvis/MSVis/MSAnalysis.h:30,
                    from /var/scratch/casarest/msvis/MSVis/MSAnalysis.cc:27:
   /opt/archive/2012-03-21-03-30/casacore/include/casacore/images/Images/ImageInterface.h:37:44: error: images/Images/ImageAttrHandler.h: No such file or directory

I think this is just because the new header files added in r21200 aren't being 
installed properly. The attached trivial change to images/CMakeLists.txt should 
fix things.

and report on ReleaseVersion14.

What steps will reproduce the problem?
1. ./batchbuild.py test
2.
3.

What is the expected output? What do you see instead?

tSparseDiff fails.


What version of the product are you using? On what operating system?

casacore-0.3.0patched.tar.bz2
SuSE 10.3
gcc 4.2.2


Please provide any additional information below.

The test program fails at line 400 in the area of

   y = pow(w,z);
    if (y.value() != Float(pow(w.value(), z.value())) ||
    (y.derivative(0).second !=
     (Float(z.value()*pow(w.value(),z.value()-1))*
      w.derivative(0).second) ||
     (y.derivative(1).second !=
      Float(pow(w.value(),z.value())*log(w.value()))*
      z.derivative(0).second))) {
      cerr << "pow(const SparseDiff<T> &, const SparseDiff<T> &) failed" <<
endl;
      nerr++;
    };

Doing a little checking, it seems that on my system there were differences
on the order of 3E-8 relative, so well below the precision of a float.  I
suspect the differences were showing up as a result of gcc not forcing a
true conversion to a float.  Changing the testing to

    y = pow(w,z);
    if (!near(y.value(), Float(pow(w.value(), z.value())), 1E-7) ||
    !near(y.derivative(0).second,
              (Float(z.value()*pow(w.value(),z.value()-1))*
               w.derivative(0).second), 1E-7) ||
        !near(y.derivative(1).second,
              Float(pow(w.value(),z.value())*log(w.value()))*
              z.derivative(0).second, 1E-7)) {
      cerr << "pow(const SparseDiff<T> &, const SparseDiff<T> &) failed" <<
endl;
      nerr++;
    };

eliminates the failure, but I don't know if you are really trying to check
that the float conversion works.

see https://svn.atnf.csiro.au/trac/asap/ticket/150

What steps will reproduce the problem?
1. Checkout casacore trunk
2. Build with clang/llvm 3.0

The attached patch fixes a number of errors and a few of the more annoying 
warnings. I have verified the tests that pass when compiled with GCC still pass 
with clang. One particular class of change in the patch perhaps begs some 
explanation, since GCC will happily compile invalid C++ code. Take this example 
code:

void f(int x)
{
    std::cout << "Global" << std::endl;
}

template <typename T> struct Base {
  void f(T x) {
      std::cout << "Base"<< std::endl;
  };
};

template <typename T> struct Derived : public Base<T> {
  void work(T x) {
    f(x);
  }
};

int main(int argc, char *argv[])
{
    Derived<int> d;
    d.work(1);
}

Both GCC and clang/llvm will compile this and will print "Global". If you 
remove the global f() (leaving Base::f()) then, GCC will compile it and print 
"Base" while clang/llvm will report an error:

program.cc:18:5: error: use of undeclared identifier 'f'
    f(x);
    ^
    this->
program.cc:25:7: note: in instantiation of member function 
'Derived<int>::work' requested here
    d.work(1);
      ^
program.cc:11:8: note: must qualify identifier to find this declaration 
in dependent base class
  void f(T x) {

The required behaviour is described in the C++ standard:

"In the definition of a class template or in the definition of a member of such 
a template that appears outside
of the template definition, if a base class of this template depends on a 
template-parameter, the base class
scope is not examined during name lookup until the class template is 
instantiated."

In the patch I have made all method calls dependent by prefixing them with 
"this->"

Further info can be found here:
http://www.parashift.com/c++-faq-lite/templates.html#faq-35.19
http://www.parashift.com/c++-faq-lite/templates.html#faq-35.20

What steps will reproduce the problem?
1. Open the attached MS
2. perform a query on it including the DATA column
3. access the sub-table DATA column

What is the expected output? What do you see instead?
Access to the DATA column is expected but get the following error:
  File "error_test.py", line 14, in <module>
    data = subt.getcol('DATA')
  File "/opt/pyrap/python/pyrap.tables-0.3.0_r308-py2.6-linux-i686.egg/pyrap/tables/table.py", line 856, in getcol
    return self._getcol (columnname, startrow, nrow, rowincr)
RuntimeError: ArrayBase::Array(const IPosition&) - Negative shape

What version of the product are you using? On what operating system?
13463, linux 32bit

Please provide any additional information below.
Attached is a pyrap script that demonstrates the issue. The same
happens in casapy using the tb toolkit so I think the problem is in
casacore rather than pyrap.

What steps will reproduce the problem?
1. svn co http://casacore.googlecode.com/svn/trunk casacore
2. cd casacore
3. python batchbuild.py

What is the expected output? What do you see instead?

Build immediately fails with:

[oms@dylan casacore]$ python batchbuild.py
Building package: casa
scons  install prefix=/home/oms/casacore/casacore/stage
casacoreroot=/home/oms/casacore/casacore/stage
scons: Reading SConscript files ...
KeyError: 'linux2':
  File "/home/oms/casacore/casacore/casa/SConstruct", line 44:
    env.Tool('casa', env["casashrdir"])
  File "/usr/lib/scons-0.97.0d20071212/SCons/Environment.py", line 1516:
    tool(self)
  File "/usr/lib/scons-0.97.0d20071212/SCons/Tool/__init__.py", line 175:
    apply(self.generate, ( env, ) + args, kw)
  File "/home/oms/casacore/casacore/casa/tools/casa.py", line 72:
    AddCasaPlatform()
  File "/home/oms/casacore/casacore/casa/tools/casa.py", line 53:
    platfdefs += pd[sysplf]
[oms@dylan casacore]$


What version of the product are you using? On what operating system?

casacore trunk, fresh from the svn repository.
Debian etch
Linux dylan 2.6.18-5-686 #1 SMP Mon Dec 24 16:41:07 UTC 2007 i686 GNU/Linux
SCons by Steven Knight et al.:
        engine: v0.97.0d20071212.r2523, 2007/12/12 09:37:41, by knight on
bangkok
Same problem with scons 0.98.

Please provide any additional information below.

casacore-0.3.0 release does not have this problem.

Hello,


tried to compile casacore on a freshly installed Linux Mint system (essentially 
this is Debian Testing). The gcc/g++ versions are 4.6.1

Both using scons and cmake didn't work - there was the same error:

In file included from /opt/casacore-1.3.0/casa/Arrays/ArrayBase.h:34:0,
                 from /opt/casacore-1.3.0/casa/Arrays/Array.h:32,
                 from /opt/casacore-1.3.0/casa/Arrays/ArrayMath.h:34,
                 from /opt/casacore-1.3.0/casa/Arrays/Array2Math.cc:28:
/opt/casacore-1.3.0/casa/Arrays/IPosition.h:358:13: error: ‘ptrdiff_t’ does 
not name a type
In file included from /opt/casacore-1.3.0/casa/Arrays/Array.h:33:0,
                 from /opt/casacore-1.3.0/casa/Arrays/ArrayMath.h:34,
                 from /opt/casacore-1.3.0/casa/Arrays/Array2Math.cc:28:
/opt/casacore-1.3.0/casa/Containers/Block.h:310:11: error: ‘ptrdiff_t’ does 
not name a type
In file included from /opt/casacore-1.3.0/casa/Arrays/ArrayMath.h:34:0,
                 from /opt/casacore-1.3.0/casa/Arrays/Array2Math.cc:28:
/opt/casacore-1.3.0/casa/Arrays/Array.h:593:15: error: ‘ptrdiff_t’ does not 
name a type
/opt/casacore-1.3.0/casa/Arrays/Array.h:631:15: error: ‘ptrdiff_t’ does not 
name a type
make[2]: *** [casa/CMakeFiles/casa_casa.dir/Arrays/Array2Math.cc.o] Error 1
make[1]: *** [casa/CMakeFiles/casa_casa.dir/all] Error 2
make: *** [all] Error 2


Switching back to gcc/g++ v4.4 did the trick:

scons --with-cc=/usr/bin/gcc-4.4 --with-cxx=/usr/bin/g++-4.4 --prefix=/tmp 
--wcs-root=/opt/



Regards,

Enno

What steps will reproduce the problem?
1.  scons --prefix=/home/vmware/WorkDir/casacore_1.0.0/mpp_build/usr
--data-dir=/usr/share/casacore/measures_data --cfitsio-libdir=/usr/lib64
install

Fails with:
scons: Reading SConscript files ...
Checking for C library dl... yes
Checking for C library gfortran... yes
Checking for C library blas... yes
Checking for C library lapack... yes
Checking for C library cfitsio... no
Checking for C header file /usr/include/libcfitsio0/fitsio.h... yes
Checking for c() in C library cfitsio... no

But the libs exist (and work):
-----------------------------
>ls -la /usr/lib64/libcfitsio.*
-rw-r--r-- 1 root root 5993498 2008-12-03 10:27 /usr/lib64/libcfitsio.a
lrwxrwxrwx 1 root root      15 2009-12-17 13:41 /usr/lib64/libcfitsio.so ->
libcfitsio.so.0
-rwxr-xr-x 1 root root 1382064 2008-12-03 10:27 /usr/lib64/libcfitsio.so.0

Scons version:
--------------
scons --version
SCons by Steven Knight et al.:
    script: v1.2.0.d20090223.r4043, 2009/02/23 09:06:45, by scons on scons-dev
    engine: v1.2.0.d20090223.r4043, 2009/02/23 09:06:45, by scons on scons-dev
Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 The
SCons Foundation


What is the expected output? What do you see instead?
Expect to build 

What version of the product are you using? On what operating system?
1.0.0
openSuse 11.1 - both 64bit and 32bit fail (with --cfitsio-libdir set
appropriately)

Hi Ger,
tRecord is failing under OSX 10.7.


It only fails for ArrayComplex and not ArrayDComplex.

According to Max it is due to a known compiler issue in std::abs which is used 
in std::compare when the difference of the values is very small.

How should we address this?

What steps will reproduce the problem?
1. ./batchbuild.py test
2.
3.

What is the expected output? What do you see instead?

./tMSSimulator.exec: line 6: assay: command not found


What version of the product are you using? On what operating system?

casacore-0.3.0patched.tar.bz2

Please provide any additional information below.


In the file casacore-0.3.0/ms/ms/MeasurementSets/test/tMSSimulator.exec

assay tMSSimulator

should be replaced by

casacore_assay tMSSimulator

I suspect

What steps will reproduce the problem?
1. when building casacore, I had to use

scons --extra-cppflags=-DNEED_FORTRAN_UNDERSCORES=0

What is the expected output? What do you see instead?

Expected output is no compiler errors. However I get an error:

./measures/Measures/SofaTest.h:201:26: error: '##' cannot appear at either end 
of a macro expansion

g++ --version is:
g++ (GCC) 4.1.2 20070115 (SUSE Linux)

What version of the product are you using? On what operating system?

using casacore 1.3.0 source tarball
compiling on SUSE Linux running on IBM Power 7 machine (ppc64).

Please provide any additional information below.

I managed to compile the code by changing the following lines in SofaTest.h:

#if NEED_FORTRAN_UNDERSCORES
#define IAUR(x) iau_##x##_
#else
#define IAUR(x) iau_##x##
#endif

to:

#if NEED_FORTRAN_UNDERSCORES
#define IAUR(x) iau_##x##_
#else
#define IAUR(x) iau_##x
#endif

I guess the extra token concatenator ## at the end of the line was a remnant of 
some copy/pasting...

On behalf of Michel Caillat

The class MSPointingColumns provides a method
setDirectionRef but it seems to not store on the ms whatever is set via
this method (care was taken to follow what is stated in the .h i.e to call
this when the pointing table has 0 rows etc)

Even did the following and it did not work...

pointingCol_p.setDirectionRef(MDirectionRef::AZEL);
//reset the ms object
ms_p.initRefs();
ms_p.flush();

To integrate better with the old aips++ build an option e.g.
NO_AUTO_TEMPLATE is necessary. This needs to be controlled via a scons
build option.

It needs:
 * _ReposFiller/templates to be replaced by the cc files it creates via mkinst
 * AIPS_NO_AUTO_TEMPLATE option added to the defines
 * scons build options added e.g. auto-template=1

We haven't tested this system yet and it should go into the new release.

When compiling casacore gcc 3.3(.4) complains about an alleged "syntax
error" in MSSummary.cc and FitGaussian.tcc. 

This is probably a bug in the old gcc, so I don't know if you want to
changes this.

The following changes get it to work again with the old gcc (I'm using
casacore out of the LOFAR-USG distribution):

horneff@kuzmin:~/usg/external/casacore> svn diff
ms/ms/MeasurementSets/MSSummary.cc
Index: ms/ms/MeasurementSets/MSSummary.cc
===================================================================
--- ms/ms/MeasurementSets/MSSummary.cc  (revision 1649)
+++ ms/ms/MeasurementSets/MSSummary.cc  (working copy)
@@ -765,7 +765,9 @@
     Vector<String> messString((msHis.message()).getColumn());
     Vector<String> messPriority((msHis.priority()).getColumn());
     for (uInt i=0 ; i < nmessages; i++) {
-      MVTime mvtime(Quantity(theTimes(i), "s"));
+      //fix to make it work with a broken gcc 3.3.(3|4)
+      Double tmpdouble=theTimes(i);
+      MVTime mvtime(Quantity(tmpdouble, "s"));
       Time messTime(mvtime.getTime());
       LogMessage::Priority itsPriority(LogMessage::DEBUGGING);
       if(messPriority(i) == "DEBUGGING"){
horneff@kuzmin:~/usg/external/casacore> svn diff
scimath/scimath/Fitting/FitGaussian.tcc
Index: scimath/scimath/Fitting/FitGaussian.tcc
===================================================================
--- scimath/scimath/Fitting/FitGaussian.tcc     (revision 1649)
+++ scimath/scimath/Fitting/FitGaussian.tcc     (working copy)
@@ -271,8 +271,10 @@
         //Eventual redundancy is very likely, so make the retry matrix bigger.
         expandRetryMatrix(1);
       }
+      //fix to make it work with a broken gcc 3.3.(3|4)
+      Time tmptime(1982,8,31,10);
+      MLCG gen(Int(tmptime.age()));

-      MLCG gen(Int(Time(1982,8,31,10).age()));
       //DiscreteUniform retgen(&gen, -nRetryFactors(), nRetryFactors()-1);
       // any negative number means use the unaltered estimate (50% chance)

@@ -592,8 +594,10 @@
       rt(r,p) = itsRetryFctr(r,p);
     }
   }
-
-  MLCG gen(Int(Time(1982,8,31,10).age()));
+
+  //fix to make it work with a broken gcc 3.3.(3|4)
+  Time tmptime(1982,8,31,10);
+  MLCG gen(Int(tmptime.age()));
   Uniform fgen(&gen, 0.0, 1.0);

   for (uInt r = initnrows; r < initnrows + rowstoadd; r++)
horneff@kuzmin:~/usg/external/casacore>  

Hello casacore member ;)

i try to install casacore and it's failed with the scons error :
SConsEnvironment instance has no attribute 'CXXFile'
You can see the log after.
But i don't know how work scons ! If someone have an idea of my problem ?

and Have you a mailling list for this question because i think is not the
god place for this question ??

bye.

LM.

What steps will reproduce the problem?
1. ./batchbuild.py prefix=/usr/local install
2. scons failed in package tables

What is the expected output? What do you see instead?
...
...
Install file: "tools/installer.py" as "/usr/local/share/casacore/installer.py"
Install file: "tools/utils.py" as "/usr/local/share/casacore/utils.py"
scons: done building targets.
Building package: tables
scons  prefix=/usr/local install casacoreroot=/usr/local
scons: Reading SConscript files ...
AttributeError: SConsEnvironment instance has no attribute 'CXXFile':
  File "/home/embrace/temp/casacore-0.3.0/tables/SConstruct", line 66:
    duplicate=0, exports=["buildenv", "installer"])
  File "/usr/lib/scons/SCons/Script/SConscript.py", line 533:
    return apply(_SConscript, [self.fs,] + files, subst_kw)
  File "/usr/lib/scons/SCons/Script/SConscript.py", line 256:
    exec _file_ in call_stack[-1].globals
  File "/home/embrace/temp/casacore-0.3.0/tables/tables/SConscript", line 9:
    ff = myenv.CXXFile(File(f), CXXFILESUFFIX=".lcc")

What version of the product are you using? On what operating system?
casacore version casacore-0.3.0patched.tar.bz2
on linux debian etch with a upgraded scons to :

alaska:/home/embrace/temp# scons --version
SCons by Steven Knight et al.:
        engine: v0.97.0d20071212.r2523, 2007/12/12 09:37:41, by knight on
bangkok

Note:
list of file in  /usr/local/share/casacore/ :
-rw-r--r-- 1 root staff 5276 2008-01-22 06:05 assaytest.py
-rw-r--r-- 1 root staff 5968 2008-02-26 14:17 assaytest.pyc
-rw-r--r-- 1 root staff  347 2007-10-26 05:43 buildenv.py
-rw-r--r-- 1 root staff  726 2008-02-26 14:17 buildenv.pyc
-rwxr-xr-x 1 root staff 6533 2007-02-28 11:34 casacore_assay
-rw-r--r-- 1 root staff 1628 2008-02-13 02:25 casaoptions.py
-rw-r--r-- 1 root staff 2557 2008-02-26 14:17 casaoptions.pyc
-rw-r--r-- 1 root staff 3026 2008-01-09 01:11 casa.py
-rw-r--r-- 1 root staff 2281 2008-02-26 14:17 casa.pyc
-rw-r--r-- 1 root staff 4230 2008-02-20 05:54 installer.py
-rw-r--r-- 1 root staff 5088 2008-02-26 14:17 installer.pyc
-rw-r--r-- 1 root staff 4149 2008-01-09 01:10 utils.py
-rw-r--r-- 1 root staff 4845 2008-02-26 14:17 utils.pyc

What steps will reproduce the problem?
1. Using the example code for the Sinusoid1D functional
http://www.astron.nl/casacore/trunk/casacore/doc/html/classcasa_1_1Sinusoid1D.ht
ml
2.
3.

What is the expected output? What do you see instead?
The output is as expected but differs from what is in the
documentation, which is off by pi/2.
Instead of -4.911 and 1.0, I get -0.9369 and ~0.0

What version of the product are you using? On what operating system?
< 2 weeks old, from nrao svn, on linux

Please provide any additional information below.
Also I think the the first line in the example should
read:
Sinusoid1D<Double> sf(5.0, 25.0, 7);
instead of:
Sinusoid<Double> sf(5.0, 25.0, 7);

Currently FITS images with Azimuth Elevation coordinates using the ALON and 
ALAT WCS keywords (with -STG projection) give the following error when loaded 
with casaviewer and when opened for conversion to CASA images with casacore.

$ casaviewer dummy.fits
==>  Dynamic session lookup supported but failed: launchd did not provide a 
socket path, verify that org.freedesktop.dbus-session.plist is loaded!
2010-11-30 15:45:17 WARN    FITSCoordinateUtil::fromFITSHeader  ALON and ALAT are 
unsupported LON/LAT types
2010-11-30 15:45:17 WARN    FITSImage::getImageAttributes (file 
images/Images/FITSImage.cc, line 509)   No proper coordinate system defined in 
FITS file. Using dummy linear system instead.

The system then falls back to a dummy linear coordinate system.
When given the wrong labels '??LN-STG' and '??LT-STG' the casaviewer falls back 
to J2000 and gives the coordinates and projection correctly but puts 'J2000 
Right ascension' and 'J2000 declination' as axes labels instead of the correct 
Azimuth and Elevation (which DO work for CASA images).
The fallback method however only works for NAXIS=2.

flex -t -PMSCorrGram ms/MeasurementSets/MSCorrGram.ll >
build_linux_i686/opt/MeasurementSets/MSCorrGram.lcc
bison -p MSCorrGram -o build_linux_i686/opt/MeasurementSets/MSCorrGram.ycc
ms/MeasurementSets/MSCorrGram.yy
g++ -o build_linux_i686/opt/MeasurementSets/MSCorrGram.o -c -O2
-I/dop172_0/bout/usr/include -I.
-I/dop172_0/bout/usr/src/casacore/stage/include/casacore
-Ibuild_linux_i686/opt/MeasurementSets ms/MeasurementSets/MSCorrGram.cc
g++ -o build_linux_i686/opt/MeasurementSets/MSSourceColumns.o -c -O2
-I/dop172_0/bout/usr/include -I.
-I/dop172_0/bout/usr/src/casacore/stage/include/casacore
-Ibuild_linux_i686/opt/MeasurementSets ms/MeasurementSets/MSSourceColumns.cc
In file included from ms/MeasurementSets/MSCorrGram.cc:46:
build_linux_i686/opt/MeasurementSets/MSCorrGram.ycc: In function 'int
MSCorrGramparse()':
build_linux_i686/opt/MeasurementSets/MSCorrGram.ycc:1447: warning:
deprecated conversion from string constant to 'char*'
build_linux_i686/opt/MeasurementSets/MSCorrGram.ycc:1593: warning:
deprecated conversion from string constant to 'char*'
g++ -o build_linux_i686/opt/MeasurementSets/MSScanParse.o -c -O2
-I/dop172_0/bout/usr/include -I.
-I/dop172_0/bout/usr/src/casacore/stage/include/casacore
-Ibuild_linux_i686/opt/MeasurementSets ms/MeasurementSets/MSScanParse.cc
g++ -o build_linux_i686/opt/MeasurementSets/MSColumns.o -c -O2
-I/dop172_0/bout/usr/include -I.
-I/dop172_0/bout/usr/src/casacore/stage/include/casacore
-Ibuild_linux_i686/opt/MeasurementSets ms/MeasurementSets/MSColumns.cc
g++ -o build_linux_i686/opt/MeasurementSets/MSObsColumns.o -c -O2
-I/dop172_0/bout/usr/include -I. -I/dop172_0/bout

Create a wiki page for using the new rc system replacing aipsrc.

What steps will reproduce the problem?
1. create a file $HOME/.casarc containing ${} as part of some paths.
For example:
measures.DE200.directory: ${CASACORE_SW_DIR}/data/ephemerides
measures.DE405.directory: ${CASACORE_SW_DIR}/data/ephemerides
measures.line.directory: ${CASACORE_SW_DIR}/data/ephemerides
measures.sources.directory: ${CASACORE_SW_DIR}/data/ephemerides
measures.comet.directory: ${CASACORE_SW_DIR}/data/ephemerides
measures.ierseop97.directory: ${CASACORE_SW_DIR}/data/geodetic
measures.ierspredict.directory: ${CASACORE_SW_DIR}/data/geodetic
measures.tai_utc.directory: ${CASACORE_SW_DIR}/data/geodetic
measures.igrf.directory: ${CASACORE_SW_DIR}/data/geodetic
measures.observatory.directory: ${CASACORE_SW_DIR}/data/geodetic
2. Set environment variable CASACORE_SW_DIR to the parent directory of the 
casacore data directory
3. Run a program that uses any of the ephemerides or geodetic tables.
For example:
#include <measures/Measures/MeasTable.h>
#include <measures/Measures/MPosition.h>
#include <iostream>
int main()
{
  casa::MPosition mpos;
  casa::MeasTable::Observatory(mpos, "DWL");
  std::cout << "DWL " << mpos << std::endl;
  return 0;
}


What is the expected output? 
DWL Position: [15.0164, 1.68353, 19.9167]

What do you see instead?
2010-09-23 09:39:23     WARN    MeasIERS::fillMeas(MeasIERS::Files, Double) 
(file measures/Measures/MeasIERS.cc, line 309)      Requested data table 
Observatories cannot be found in the searched directories:
2010-09-23 09:39:23     WARN    MeasIERS::fillMeas(MeasIERS::Files, Double) 
(file measures/Measures/MeasIERS.cc, line 309)+     
${CASACORE_SW_DIR}/data/geodetic/
2010-09-23 09:39:23     SEVERE  MeasTable::initObservatories() (file 
measures/Measures/MeasTable.cc, line 4067) Cannot read table of Observatories
terminate called after throwing an instance of 'casa::AipsError'
  what():  2010-09-23 09:39:23  SEVERE  MeasTable::initObservatories() (file measures/Measures/MeasTable.cc, line 4067)Cannot read table of Observatories
Abort


What version of the product are you using? On what operating system?
Casacore 1.2

Please provide any additional information below.
Removing the {} from the environment variable(s) in the casarc-file resolves 
the problem.

What steps will reproduce the problem?
1. install without aips++ on your computer
2. ./batchbuild.py test
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?

casacore-0.3.0patched.tar.bz2
SuSE 10.3
gcc 4.2.2


Please provide any additional information below.

The relevant output from the test build is copied below.  Note that I put
an 'env' command in casacore_assay in a couple of places for debugging what
is going on, and I manually added the environment variable CASACOREROOT
within casacore_assay.

Running assay ...
CASACOREROOT=/aux/vlb054a/anderson/LOFAR_soft/casacore
LD_LIBRARY_PATH=/.aux_mnt/vlb054a/anderson/external_code/casacore-0.3.0/lattices
/build_linux_i686/opt:/aux/vlb054a/anderson/local/lib:/.aux_mnt/vlb054a/anderson
/external_code/casacore-0.3.0/stage/lib:/.aux_mnt/vlb054a/anderson/external_code
/casacore-0.3.0/lattices/build_linux_i686/opt:/aux/vlb054a/anderson/local/lib:/.
aux_mnt/vlb054a/anderson/external_code/casacore-0.3.0/stage/lib
PATH=/aux/vlb054a/anderson/local/bin:/aux/vlb054a/anderson/gcc/4.2/bin:/aux/vlb0
54a/anderson/local/bin:/aux/vlb054a/anderson/gcc/4.2/bin:/aux/vlb054a/anderson/l
ocal/bin:/homes/anderson/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R
6/bin:/usr/games:/opt/kde3/bin:/usr/lib/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mi
t/sbin:/usr/lib/qt3/bin
PWD=/.aux_mnt/vlb054a/anderson/external_code/casacore-0.3.0/lattices/build_linux
_i686/opt/Lattices/test
SHLVL=1
HOME=/homes/anderson
_=/usr/bin/env
13c13
< [2, 3, 4, 3, 2, 1, -2.4774e-16, 1, 2][0, 1, 2, 3, 4, 3, 2, 1, -2.4774e-16]

---
> [2, 3, 4, 3, 2, 1, 3.14018e-16, 1, 2][0, 1, 2, 3, 4, 3, 2, 1, 0]
/aux/vlb054a/anderson/local/bin:/aux/vlb054a/anderson/gcc/4.2/bin:/aux/vlb054a/a
nderson/local/bin:/aux/vlb054a/anderson/gcc/4.2/bin:/aux/vlb054a/anderson/local/
bin:/homes/anderson/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin
:/usr/games:/opt/kde3/bin:/usr/lib/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbi
n:/usr/lib/qt3/bin
CASACOREROOT=/aux/vlb054a/anderson/LOFAR_soft/casacore
LD_LIBRARY_PATH=/.aux_mnt/vlb054a/anderson/external_code/casacore-0.3.0/lattices
/build_linux_i686/opt:/aux/vlb054a/anderson/local/lib:/.aux_mnt/vlb054a/anderson
/external_code/casacore-0.3.0/stage/lib:/.aux_mnt/vlb054a/anderson/external_code
/casacore-0.3.0/lattices/build_linux_i686/opt:/aux/vlb054a/anderson/local/lib:/.
aux_mnt/vlb054a/anderson/external_code/casacore-0.3.0/stage/lib
PATH=/aux/vlb054a/anderson/local/bin:/aux/vlb054a/anderson/gcc/4.2/bin:/aux/vlb0
54a/anderson/local/bin:/aux/vlb054a/anderson/gcc/4.2/bin:/aux/vlb054a/anderson/l
ocal/bin:/homes/anderson/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R
6/bin:/usr/games:/opt/kde3/bin:/usr/lib/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mi
t/sbin:/usr/lib/qt3/bin
PWD=/.aux_mnt/vlb054a/anderson/external_code/casacore-0.3.0/lattices/build_linux
_i686/opt/Lattices/test
SHLVL=1
HOME=/homes/anderson
_=/usr/bin/env
FAIL (floating point discrepancies > 1e-5): ./tPixelCurve1D
/.aux_mnt/vlb054a/anderson/external_code/casacore-0.3.0/stage/share/casacore/cas
acore_assay:
line 207: floatcheck.sh: command not found

There is a floatcheck.sh in the distribution

find . -name floatcheck.sh -print
./install/floatcheck.sh

but it is not in the path.  The build system needs to put this into a place
where it is in the path, or to change the path to include the file.  I
suspect that when you run the test build, your aips++ floatcheck.sh gets found.

Attached files t1c.fits and t1l.fits illustrate the problem. They are the
result of regridding input_rg.fits with the program rgtest.cc and
correspond to different pixel interpolation method used (cubic and linear
respectively).

Notice the strangely rugged borders of the image, and especially the
difference between linear and cubic interpolation. To clearly illustrate
that the problem originates in the mask and not the filling value provided
script will create one more image (res2c.fits) where masked out part of the
image is forced to be 0. As an extra try -- comment out lines 29 and 30,
and rerun the script -- image boundaries will come out nicely when input
image has no mask.

Rebuilding casacore (revision 20385, on a Mac) I found that "batchbuild
install" crashes if the prefix is not given (default location is supposed 
to be /usr/local according to the script). The crash is caused by "scons
install" inside tables (i.e. casa compiles without any problem) when it can't
find casaoptions.py. I found that casaoptions.py is placed to
/usr/share/casacore instead of /usr/local/share/casacore when the prefix is
not given. Specifying prefix (as in the build instructions) solves the problem.

We need a new release to expose fix for array slicing and compatibility with 
more recent gcc revisions.

What steps will reproduce the problem?
1. ./batchbuild.py test
2.
3.

What is the expected output? What do you see instead?

casa/casa/Arrays/test/tArrayIter.cc fails to compile because g++ 4.2.2 does
not like line 229

cout << subarr << endl;

As it cannot find a proper operator<< for subarr.

What version of the product are you using? On what operating system?

I have casacore-0.3.0patched.tar.bz2, SuSE 10.3


Please provide any additional information below.

#include <casa/Arrays/ArrayIO.h>

in the top fixes the problem.