juliaastro / fitsio.jl Goto Github PK
View Code? Open in Web Editor NEWFlexible Image Transport System (FITS) file support for Julia
Home Page: http://juliaastro.org/FITSIO.jl/
License: MIT License
Flexible Image Transport System (FITS) file support for Julia
Home Page: http://juliaastro.org/FITSIO.jl/
License: MIT License
Besides integration with Images.jl
, it may be useful to have integration with Plots.jl
. This can be achieved with plot recipes. I recently used them in Measurements.jl
, they're pretty cool. If there are WCS coordinates, they could be automatically used as tics on the axes.
I'm having trouble reading a column from a binary table. The file is from this URL. I'm new to FITS, so apologies in advance if I'm missing something basic.
I would like to read the RROWS column. It is present:
psf_filename = "psField-003900-6-0269.fit"
psf_fits = FITS(psf_filename);
read_header(psf_fits[b + 1])
# ...other fields...
# TFORM7 = '1J' / PIXDATATYPE
# TTYPE7 = 'RTYPE' / type
# TFORM8 = '1PE(0)' / FLOAT
# TTYPE8 = 'RROWS' / rows_fl32
# TFORM9 = '1J' / INT
# TTYPE9 = 'RROW0' / row0
# TFORM10 = '1J' / INT
# TTYPE10 = 'RCOL0' / col0
# ....
And I can read other fields:
read(psf_fits[b + 1], "RNROW")
#4-element Array{Int32,1}:
# 51
# 51
# 51
# 51
But I cannot read RROWS:
read(psf_fits[b + 1], "RROWS")
# ERROR: key not found: -42
# in read at /home/rgiordan/.julia/v0.3/FITSIO/src/hdutypes.jl:72
Any idea what might be going wrong?
How can we convert a FITSHeader in a String format and vice-versa?
It would be great to modify a Header by making a WCSTransform object, making the changes and then saving that to original FITS file.
Using to_header
from WCS.jl
, we can get the header in string format but how can I write that to a FITSHeader?
Since images have the element type in the header (and this is something that CFITSIO converts to a Julia type), it should be possible to obtain the element type of an image HDU using something like this :
julia> FITS("V_kw.fits", "r") do f
eltype(f[1])
end
Currently this returns Any
, but a suitable method may be added to return the correct element type.
With Julia 0.4 (the release candidate) I'm getting a lot of warnings about Uint8/UInt8 from just a few lines of FITSIO.jl. For example,
WARNING: Base.Uint8 is deprecated, use UInt8 instead.
in fits_hdr2str at /home/travis/.julia/v0.4/FITSIO/src/libcfitsio.jl:410
WARNING: Base.Uint8 is deprecated, use UInt8 instead.
in fits_hdr2str at /home/travis/.julia/v0.4/FITSIO/src/libcfitsio.jl:410
WARNING: Base.Uint8 is deprecated, use UInt8 instead.
in fits_hdr2str at /home/travis/.julia/v0.4/FITSIO/src/libcfitsio.jl:410
WARNING: Base.Uint8 is deprecated, use UInt8 instead.
in fits_hdr2str at /home/travis/.julia/v0.4/FITSIO/src/libcfitsio.jl:410
WARNING: Base.Uint8 is deprecated, use UInt8 instead.
in fits_hdr2str at /home/travis/.julia/v0.4/FITSIO/src/libcfitsio.jl:410
WARNING: Base.Uint8 is deprecated, use UInt8 instead.
WARNING: Base.Uint8 is deprecated, use UInt8 instead.
in fits_hdr2str at /home/travis/.julia/v0.4/FITSIO/src/libcfitsio.jl:410
WARNING: Base.Uint8 is deprecated, use UInt8 instead.
in fits_hdr2str at /home/travis/.julia/v0.4/FITSIO/src/libcfitsio.jl:410
WARNING: Base.Uint8 is deprecated, use UInt8 instead.
in wcspih at /home/travis/.julia/v0.4/WCSLIB/src/libwcs_h.jl:518
WARNING: Base.Uint8 is deprecated, use UInt8 instead.
in wcspih at /home/travis/.julia/v0.4/WCSLIB/src/libwcs_h.jl:518
WARNING: Base.Uint8 is deprecated, use UInt8 instead.
WARNING: Base.Uint8 is deprecated, use UInt8 instead.
in wcspih at /home/travis/.julia/v0.4/WCSLIB/src/libwcs_h.jl:518
WARNING: Base.Uint8 is deprecated, use UInt8 instead.
Hello all,
I don't want to be too much of a bother, but I need a new tag of FITSIO.jl that includes #66 to use as a lower limit for LibHealpix.jl. Is there any chance of having a new version tagged in the not-so-distant future?
Thanks!
This works in python but not julia:
In [1]: from astropy.io import fits
In [2]: import numpy as np
In [3]: fits.writeto("abc[12].fits", np.ones((2,2)))
In [4]: fits.getdata("abc[12].fits")
Out[4]:
array([[1., 1.],
[1., 1.]])
and
julia> using FITSIO
julia> FITSIO.fitsread("abc[12].fits")
ERROR: While processing file `abc[12].fits`: parse error in input file URL
I cannot open a zipped FITS file (astropy has no problem, though).
julia> using FITSIO, PyCall
julia> download("https://www.spacetelescope.org/static/projects/fits_liberator/datasets/eagle/502nmos.zip", "502nmos.zip")
"502nmos.zip"
julia> py"""import astropy
print(astropy.__version__)
"""
3.2.3
julia> pf = pyimport("astropy.io.fits")
PyObject <module 'astropy.io.fits' from '/Users/miles/.pyenv/versions/3.7.4/Python.framework/Versions/3.7/lib/python3.7/site-packages/astropy/io/fits/__init__.py'>
julia> pf.open("502nmos.zip")
2-element Array{PyObject,1}:
PyObject <astropy.io.fits.hdu.image.PrimaryHDU object at 0x1469b0390>
PyObject <astropy.io.fits.hdu.table.TableHDU object at 0x1469ad0d0>
julia> FITS("502nmos.zip")
ERROR: While processing file `502nmos.zip`: error uncompressing image
Stacktrace:
[1] error(::String) at /Applications/Julia-1.4.app/Contents/Resources/julia/lib/julia/sys.dylib:?
[2] fits_assert_ok at /Users/miles/.julia/packages/FITSIO/BavHZ/src/libcfitsio.jl:206 [inlined]
[3] fits_open_file(::String, ::Int64) at /Users/miles/.julia/packages/FITSIO/BavHZ/src/libcfitsio.jl:281
[4] FITS(::String, ::String) at /Users/miles/.julia/packages/FITSIO/BavHZ/src/FITSIO.jl:109 (repeats 2 times)
[5] top-level scope at REPL[33]:1
[6] eval(::Module, ::Any) at /Applications/Julia-1.4.app/Contents/Resources/julia/lib/julia/sys.dylib:?
[7] eval_user_input(::Any, ::REPL.REPLBackend) at /Applications/Julia-1.4.app/Contents/Resources/julia/lib/julia/sys.dylib:?
[8] run_backend(::REPL.REPLBackend) at /Users/miles/.julia/packages/Revise/AMRie/src/Revise.jl:1023
[9] top-level scope at none:0
relevant manifest info:
[525bcba6] FITSIO v0.14.0
[438e738f] PyCall v1.91.4
Can we stream data in via a url?
e.g.
using FITSIO
url = "https://dr14.sdss.org/optical/spectrum/view/data/format=fits/spec=lite?plateid=1323&mjd=52797&fiberid=12"
f = FITS(url)
If we can't stream it, can we at least let the above look like this->
using FITSIO
url = "https://dr14.sdss.org/optical/spectrum/view/data/format=fits/spec=lite?plateid=1323&mjd=52797&fiberid=12"
# This happens behind the scenes when user calls FITS(url)
f = FITS(download(url))
This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml
to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
In version 0.16 this getindex
method stopped working (works in 0.15):
Line 111 in ac1e773
UndefVarError: fits_movnam_hdu not defined
Stacktrace:
[1] getindex(::FITSIO.FITS, ::String, ::Int64) at /home/runner/.julia/packages/FITSIO/KYCVW/src/fits.jl:113
[2] getindex at /home/runner/.julia/packages/FITSIO/KYCVW/src/fits.jl:112 [inlined]
The fits_movnam_hdu
function is indeed used here:
Line 113 in ac1e773
It's been a year since the previous release. There have been a few PRs merged in the interim, tagging a new release might be worth it?
It seems that fits_get_colnum is set-up to be always case insensitive.
I know a fair number of astronomical catalogs that use case-sensitive column names.
The Gaia DR2 catalog (as offered on CDS ViZieR) released yesterday is one of them (e.g. the b_Teff and B_Teff columns).
It would be great to make it case sensitive by default.
thanks
I am able to open compressed FITS files with 1-3 dimension image data. However, for files with data cubes with more than 3 dimensions, trying to read the "image" produces ERROR: error uncompressing image
.
Minimal example:
using FITSIO
img = FITS("test2d.fits", "w")
dc = FITS("test4d.fits", "w")
data = rand(Int16, 10000)
write(img, reshape(data, (100, 100)))
write(dc, reshape(data, (10, 10, 10, 10)))
close(img)
close(dc)
run(`fpack test2d.fits`)
run(`fpack test4d.fits`)
compressed_img = FITS("test2d.fits.fz")
compressed_dc = FITS("test4d.fits.fz")
works = read(compressed_img[2])
fails = read(compressed_dc[2])
I'd like to be able to safely modify wcsprm structs (as returned by WCSLIB.jl's wcspih function) in julia. For example, I'd like to be able to set the crpix field (the pixel reference point) when I subset an image.
However, the field is a C pointer:
julia> blob[1].wcs.crpix Ptr{Float64} @0x000000000f550a50
...so the only way to modify it is the aptly-named unsafe_store!
. This isn't great -- for example, this seems to mean that deepcopy
of types containing a wcsprm
object doesn't actually deeply copy the object.
Is there any hope for changing some of these fields to julia values rather than C pointers?
PackageEvaluator.jl is a script that runs nightly. It attempts to load all Julia packages and run their tests (if available) on both the stable version of Julia (0.3) and the nightly build of the unstable version (0.4). The results of this script are used to generate a package listing enhanced with testing results.
Tests pass.
Tests fail, but package loads.
Tests pass.
means that PackageEvaluator found the tests for your package, executed them, and they all passed.
Tests fail, but package loads.
means that PackageEvaluator found the tests for your package, executed them, and they didn't pass. However, trying to load your package with using
worked.
This issue was filed because your testing status became worse. No additional issues will be filed if your package remains in this state, and no issue will be filed if it improves. If you'd like to opt-out of these status-change messages, reply to this message saying you'd like to and @IainNZ will add an exception. If you'd like to discuss PackageEvaluator.jl please file an issue at the repository. For example, your package may be untestable on the test machine due to a dependency - an exception can be added.
Test log:
>>> 'Pkg.add("FITSIO")' log
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 4541k 100 4541k 0 0 4082k 0 0:00:01 0:00:01 --:--:-- 4083k
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for gfortran... gfortran
checking whether we are using GNU Fortran...
yes
cfitsio: == Adding wrapper support for GNU Fortran...
done
... truncated ...
a - zlib/inftrees.o
a - zlib/trees.o
a - zlib/uncompr.o
a - zlib/zcompress.o
a - zlib/zuncompress.o
a - zlib/zutil.o
a - f77_wrap1.o
a - f77_wrap2.o
a - f77_wrap3.o
a - f77_wrap4.o
/bin/cp -a libcfitsio* /home/idunning/pkgtest/.julia/v0.3/FITSIO/deps/usr/lib
/bin/cp fitsio.h fitsio2.h longnam.h drvrsmem.h /home/idunning/pkgtest/.julia/v0.3/FITSIO/deps/usr/include
/bin/cp cfitsio.pc /home/idunning/pkgtest/.julia/v0.3/FITSIO/deps/usr/lib/pkgconfig
INFO: Cloning cache of FITSIO from git://github.com/JuliaAstro/FITSIO.jl.git
INFO: Installing BinDeps v0.3.0
INFO: Installing FITSIO v0.4.0
INFO: Installing SHA v0.0.2
INFO: Installing URIParser v0.0.2
INFO: Building FITSIO
INFO: Attempting to Create directory /home/idunning/pkgtest/.julia/v0.3/FITSIO/deps/downloads
INFO: Downloading file ftp://heasarc.gsfc.nasa.gov/software/fitsio/c/cfitsio3360.tar.gz
INFO: Done downloading file ftp://heasarc.gsfc.nasa.gov/software/fitsio/c/cfitsio3360.tar.gz
INFO: Attempting to Create directory /home/idunning/pkgtest/.julia/v0.3/FITSIO/deps/src
INFO: Attempting to Create directory /home/idunning/pkgtest/.julia/v0.3/FITSIO/deps
INFO: Directory /home/idunning/pkgtest/.julia/v0.3/FITSIO/deps already created
INFO: Attempting to Create directory /home/idunning/pkgtest/.julia/v0.3/FITSIO/deps/src/cfitsio
INFO: Changing Directory to /home/idunning/pkgtest/.julia/v0.3/FITSIO/deps/src/cfitsio
INFO: Package database updated
INFO: METADATA is out-of-date a you may not have the latest version of FITSIO
INFO: Use `Pkg.update()` to get the latest versions of your packages
>>> 'using FITSIO' log
>>> test log
ERROR: type: ccall: expected Symbol, got Array{Any,1}
in include at ./boot.jl:245
in include_from_node1 at loading.jl:128
in process_options at ./client.jl:285
in _start at ./client.jl:354
in _start_3B_1699 at /home/idunning/julia03/usr/bin/../lib/julia/sys.so
while loading /home/idunning/pkgtest/.julia/v0.3/FITSIO/test/runtests.jl, in expression starting on line 11
>>> end of log
In the long term, I think it will become a nightmare having the dual interface that currently exists in this package. Instead, we should ensure that the high-level interface has all the functionality and performance possible in the low-level interface and eventually deprecate the low-level interface for public use. (I've been putting off having this discussion because it might be contentious, but it will be better to resolve sooner rather than later!)
Obviously there are still gaps in the high-level interface, the most glaring of which is support for tables. I'm currently working on a PR to support tables in the high-level interface (at least at the level available in the low-level interface). The other thing I can think of off the top of my head is a way to get "raw" header values as strings.
What else is missing from the high-level interface, in terms of either functionality or performance? If you're currently using the low-level API, could you switch?
I get the error below when I try to load FITSIO with Julia (Version 0.4.0-dev+4603). Is FITSIO compatible with Julia 0.4?
julia> using FITSIO
WARNING: int32(x) is deprecated, use Int32(x) instead.
in depwarn at ./deprecated.jl:40
in int32 at deprecated.jl:29
in include at ./boot.jl:250
in include_from_node1 at ./loading.jl:132
in include at ./boot.jl:250
in include_from_node1 at ./loading.jl:132
in reload_path at ./loading.jl:156
in _require at ./loading.jl:68
in require at ./loading.jl:51
ERROR: LoadError: LoadError: TypeError: apply_type: in Array, expected Type{T}, got Tuple{DataType,DataType,DataType}
in anonymous at no file:463
in include at ./boot.jl:250
in include_from_node1 at ./loading.jl:132
in include at ./boot.jl:250
in include_from_node1 at ./loading.jl:132
in reload_path at ./loading.jl:156
in _require at ./loading.jl:68
in require at ./loading.jl:51
while loading /home/jeff/.julia/v0.4/FITSIO/src/cfitsio.jl, in expression starting on line 461
while loading /home/jeff/.julia/v0.4/FITSIO/src/FITSIO.jl, in expression starting on line 70
Is there a way to modify image data in a .fits file without touching anything else?
I have a .fits file that contains image data as well as several extensions (tables). I want to replace the image data while keeping everything else (headers/extensions etc.) unchanged. Is there a way to do it?
Right now, I'm creating a new file and copying all the extensions to it:
hdul_data = FITS("input.fits")
# Load the image data
image_data = read(hdul_data[1])
# Modify data
image_data[10, 10] = 42
# Save the data array into the output fits file
data_out = FITS("output.fits", "w");
for hdu in hdul_data
if typeof(hdu)==FITSIO.ImageHDU
# Write the image to output file
write(data_out, image_data; header=header_data)
elseif typeof(hdu)==FITSIO.TableHDU
# Copy the table into the output file
table_data = Dict{String,Array}()
for colname in FITSIO.colnames(hdu)
col_data = read(hdu, colname)
table_data[colname] = col_data
end
header = read_header(hdu)
ext_name = header["EXTNAME"]
write(data_out, table_data; hdutype=FITSIO.TableHDU, header=header, name=ext_name)
end
end
This is not ideal, because I'm not sure if the new file will be exactly the same as the old one (except for the changed image). I would prefer to just modify the image data. These are example of how this could be done in Python and Fortran.
Python example:
from astropy.io import fits
hdul_data = fits.open("data.fits")
# Load the image data
image_data = hdul_data["PRIMARY"].data
# Change image data
image_data[5,5]=123
# Save the data array into the output fits file
hdul_data.writeto("output.fits")
Fortran example (cfitsio):
! Get an unused Logical Unit Number to use to open the FITS file.
call ftgiou(unit_data,status)
! Open the FITS file, with read-only access.
readwrite=0
call ftopen(unit_data,filename_data,readwrite,blocksize,status)
! Load the image data
group=1
nullval=0
call ftg2di(unit_data, group, nullval, max_x, naxes_data(1), naxes_data(2), image_data, anynull, status)
! Modify the image
image_data(10,10) = 42
! Create the output fits file
! -------------
! Get an unused Logical Unit Number to use to create the FITS file.
call ftgiou(unit_output, status)
! Create the output file
blocksize=1
call ftinit(unit_output, filename_output, blocksize, status)
! Copy the entire data file to the output file
call ftcpfl(unit_data, unit_output, 1, 1, 1, status)
! Move back to the primary array
call ftmahd(unit_output, 1, hdutype, status)
! Save the data array into the output fits file
group=1
nullval=0
call ftp2di(unit_output, group, max_x, naxes_data(1), naxes_data(2), image_data, status)
At present the compat entries are
Lines 11 to 12 in a9a14fb
Perhaps we should shift to the caret bounds from the inequalities? In any case the julia registry places an upper bound on the julia version, but apparently it doesn't on the other dependencies.
With the FITSIO package installed and Pkg.update() done, I get the following error on Kubuntu 15.04. Not sure what's going on...
Julia Version 0.3.2, x86_64-linux-gnu
julia> using OIFITS
Warning: could not import FITSIO.fits_get_errstatus into OIFITS
ERROR: FITSFile not defined
in eval at ./no file
in include212 at /usr/bin/../lib/x86_64-linux-gnu/julia/sys.so
in include_from_node11801 at /usr/bin/../lib/x86_64-linux-gnu/julia/sys.so
in include212 at /usr/bin/../lib/x86_64-linux-gnu/julia/sys.so
in include_from_node11801 at /usr/bin/../lib/x86_64-linux-gnu/julia/sys.so
in include212 at /usr/bin/../lib/x86_64-linux-gnu/julia/sys.so
in include_from_node11801 at /usr/bin/../lib/x86_64-linux-gnu/julia/sys.so
in reload_path at ./loading.jl:152
in _require at ./loading.jl:67
in require at ./loading.jl:52
while loading /home/baron/.julia/v0.3/OIFITS/src/fix-fitsio.jl, in expression starting on line 127
while loading /home/baron/.julia/v0.3/OIFITS/src/oifile.jl, in expression starting on line 17
while loading /home/baron/.julia/v0.3/OIFITS/src/OIFITS.jl, in expression starting on line 51
PR #72 dropped support for Julia 0.4, and with it Compat.ASCIIString
was replaced with String
. This type doesn't guarantee there are only ASCII character in the string, there may be places where this should be enforced, isascii
can be used for this.
Currently, we have the following HDUs:
julia> subtypes(HDU)
3-element Array{Any,1}:
ASCIITableHDU
ImageHDU
TableHDU
However the FITS expects at least one other type, "Primary HDU", see https://fits.gsfc.nasa.gov/fits_primer.html.
One example of FITS file with a Primary HDU has been reported at JuliaAstro/AstroImages.jl#9: EUVEngc4151imgx.fits
. FITSIO.jl
shows the following table:
julia> using FITSIO
julia> file = download("https://fits.gsfc.nasa.gov/samples/EUVEngc4151imgx.fits")
"/tmp/julia6zY8AX"
julia> FITS(file)
File: /tmp/julia6zY8AX
Mode: "r" (read-only)
HDUs: Num Name Type
1 Image
2 ds Image
3 sw_night Image
4 mw Image
5 lw Image
6 ds_limits Table
7 sw_night_limits Table
8 mw_limits Table
9 lw_limits Table
instead Astropy reports:
>>> from astropy.io import fits
>>> fits.open("/tmp/julia6zY8AX").info()
Filename: /tmp/julia6zY8AX
No. Name Ver Type Cards Dimensions Format
0 PRIMARY 1 PrimaryHDU 62 ()
1 ds 1 ImageHDU 72 (512, 512) int16
2 sw_night 1 ImageHDU 78 (2048, 300) int16
3 mw 1 ImageHDU 78 (2048, 300) int16
4 lw 1 ImageHDU 78 (2048, 300) int16
5 ds_limits 1 BinTableHDU 71 3R x 3C [8A, 1E, 1E]
6 sw_night_limits 1 BinTableHDU 71 2R x 3C [12A, 1E, 1E]
7 mw_limits 1 BinTableHDU 71 2R x 3C [12A, 1E, 1E]
8 lw_limits 1 BinTableHDU 71 2R x 3C [12A, 1E, 1E]
It seems writemode is not supported with fits_open_file. I get an error message when closing a fits file after writing a column to an existing file as follows.
julia> f=fits_open_file("test.fits")
FITSFile(Ptr{Nothing} @0x0000000001885840)
julia> fits_write_col(f,24,1,1,dat)
julia> fits_close_file(f)
ERROR: cannot write to readonly file
The function fits_open_file does not accept 0 or 1 for read/write mode as in cfitsio.
This is more of a discussion that I wanted to have, as I often have to work in Fourier space where arrays are complex. Since complex arrays are usually laid out contiguously in memory, it's possible to write them to FITS files by reinterpreting them as floating point arrays where the first dimension is doubled in size. Such arrays may also be read in by reinterpreting them as Complex ones of the correct type. Is this a feature that might be implemented? In that case I might consider submitting a PR.
What I currently use for complex arrays is something like floatarr = collect(reinterpret(Float64,complexarr)
before writing to FITS. This involves an extra collection --- and hence allocation --- that is unnecessary. It appears solving the write
is straightforward by expanding the type dispatched upon from Array{T}
to Union{Array{T},Base.ReinterpretArray{T}}
. I haven't looked into the read
part yet. I was wondering if this appears sensible, or if there is something that I'm missing.
This is an issue to track some obvious features that should be added. My guess is that they will be added gradually over time as needed, but in a backwards-compatible manner.
General
FITS
type: enabling for hdu in FITS(...)
show()
for FITS and HDU types. [#38]Headers
read_key(hdu, key)[1]
.Images
write(hdu, data; start=(100, 200))
read!(hdu, data)
, read!(hdu, 1:20, 1:30, data)
Tables
Base.names
but that has a different definition; maybe use colnames
) [#93]Base.length
)write(::FITS, ::Dict{Any, Vector})
(raise runtime error if any dictionary key is not ASCII)read(hdu, "COLNAME", 1:10)
read(hdu, "COLNAME", [1, 3, 6, 10])
read!(hdu, "COLNAME", data)
BitArray
s?)It always seems to try to download and build CFITSIO.
Personally, when working with a FITS table, I generally immediately put the relevant cols into a DataFrame
. This would make that easier, make it possible to simply save tables as CSV, etc.
If you think this is a good idea, I can look into doing it myself.
I was surprised that this doesn't already exist, but it's straightforward to add.
Column names are already determined as part of show(::IO, ::TableHDU)
and show(::IO, ::ASCIITableHDU)
. One would just have to pull out some of that code into a separate function.
colnames
might be a good function name for this. DataFrames extends Base.names
for this purpose, but the definition of Base.names
is, I think, inconsistent with this usage.
When I tried to add the package on a windows machine the install fails. It doesn't copy cfitsio.dll to the /lib directory. I put it there and did a Pkg.build() and everything worked.
Here's the output from the console:
julia> Pkg.add("FITSIO")
INFO: Cloning cache of FITSIO from git://github.com/JuliaAstro/FITSIO.jl.git
INFO: Installing FITSIO v0.8.3
INFO: Building FITSIO
PowerShell[.exe] [-PSConsoleFile | -Version ]
[-NoLogo] [-NoExit] [-Sta] [-Mta] [-NoProfile] [-NonInteractive]
[-InputFormat {Text | XML}] [-OutputFormat {Text | XML}]
[-WindowStyle <style>] [-EncodedCommand ]
[-File ] [-ExecutionPolicy ]
[-Command { - | [-args ]
| [] } ]
PowerShell[.exe] -Help | -? | /?
-PSConsoleFile
Loads the specified Windows PowerShell console file. To create a console
file, use Export-Console in Windows PowerShell.
-Version
Starts the specified version of Windows PowerShell.
Enter a version number with the parameter, such as "-version 2.0".
-NoLogo
Hides the copyright banner at startup.
-NoExit
Does not exit after running startup commands.
-Sta
Starts the shell using a single-threaded apartment.
Single-threaded apartment (STA) is the default.
-Mta
Start the shell using a multithreaded apartment.
-NoProfile
Does not load the Windows PowerShell profile.
-NonInteractive
Does not present an interactive prompt to the user.
-InputFormat
Describes the format of data sent to Windows PowerShell. Valid values are
"Text" (text strings) or "XML" (serialized CLIXML format).
-OutputFormat
Determines how output from Windows PowerShell is formatted. Valid values
are "Text" (text strings) or "XML" (serialized CLIXML format).
-WindowStyle
Sets the window style to Normal, Minimized, Maximized or Hidden.
-EncodedCommand
Accepts a base-64-encoded string version of a command. Use this parameter
to submit commands to Windows PowerShell that require complex quotation
marks or curly braces.
-File
Runs the specified script in the local scope ("dot-sourced"), so that the
functions and variables that the script creates are available in the
current session. Enter the script file path and any parameters.
File must be the last parameter in the command, because all characters
typed after the File parameter name are interpreted
as the script file path followed by the script parameters.
-ExecutionPolicy
Sets the default execution policy for the current session and saves it
in the $env:PSExecutionPolicyPreference environment variable.
This parameter does not change the Windows PowerShell execution policy
that is set in the registry.
-Command
Executes the specified commands (and any parameters) as though they were
typed at the Windows PowerShell command prompt, and then exits, unless
NoExit is specified. The value of Command can be "-", a string. or a
script block.
If the value of Command is "-", the command text is read from standard
input.
If the value of Command is a script block, the script block must be enclosed
in braces ({}). You can specify a script block only when running PowerShell.exe
in Windows PowerShell. The results of the script block are returned to the
parent shell as deserialized XML objects, not live objects.
If the value of Command is a string, Command must be the last parameter
in the command , because any characters typed after the command are
interpreted as the command arguments.
To write a string that runs a Windows PowerShell command, use the format:
"& {<command>}"
where the quotation marks indicate a string and the invoke operator (&)
causes the command to be executed.
-Help, -?, /?
Shows this message. If you are typing a PowerShell.exe command in Windows
PowerShell, prepend the command parameters with a hyphen (-), not a forward
slash (/). You can use either a hyphen or forward slash in Cmd.exe.
EXAMPLES
PowerShell -PSConsoleFile SqlSnapIn.Psc1
PowerShell -version 2.0 -NoLogo -InputFormat text -OutputFormat XML
PowerShell -Command {Get-EventLog -LogName security}
PowerShell -Command "& {Get-EventLog -LogName security}"
# To use the -EncodedCommand parameter:
$command = 'dir "c:\program files" '
$bytes = [System.Text.Encoding]::Unicode.GetBytes($command)
$encodedCommand = [Convert]::ToBase64String($bytes)
powershell.exe -encodedCommand $encodedCommand
INFO: Attempting to Create directory C:\Users\User.julia\v0.4\FITSIO\deps\downloads
INFO: Downloading file ftp://heasarc.gsfc.nasa.gov/software/fitsio/c/cfitsio_MSVC_64bit_DLL_3370.zip
INFO: Done downloading file ftp://heasarc.gsfc.nasa.gov/software/fitsio/c/cfitsio_MSVC_64bit_DLL_3370.zip
INFO: Attempting to Create directory C:\Users\User.julia\v0.4\FITSIO\deps\src
INFO: Attempting to Create directory C:\Users\User.julia\v0.4\FITSIO\deps
INFO: Directory C:\Users\User.julia\v0.4\FITSIO\deps already created
7-Zip [64] 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
Processing archive: C:\Users\User.julia\v0.4\FITSIO\deps\downloads\cfitsio_MSVC_64bit_DLL_3370.zip
Extracting cfitsio.dll
Extracting cfitsio.lib
Extracting FPack.exe
Extracting Funpack.exe
Extracting TestProg.exe
Extracting fpackguide.pdf
Extracting fitsio.h
Extracting License.txt
Extracting longnam.h
Extracting README.win
Extracting testprog.std
Extracting testprog.tpt
Extracting testprog.out
Extracting testprog.c
Everything is Ok
Files: 14
Size: 2161783
Compressed: 1078860
INFO: Attempting to Create directory C:\Users\User.julia\v0.4\FITSIO\deps\usr\lib
INFO: Changing Directory to C:\Users\User.julia\v0.4\FITSIO\deps\src
===============================[ ERROR: FITSIO ]================================
LoadError: could not spawn cp cfitsio.dll 'C:\Users\User\.julia\v0.4\FITSIO\deps\usr\lib\cfitsio.dll'
: no such file or directory (ENOENT)
while loading C:\Users\User.julia\v0.4\FITSIO\deps\build.jl, in expression starting on line 55
====================================================[ BUILD ERRORS ]====================================================
WARNING: FITSIO had build errors.
Pkg.build("FITSIO")
deps/build.jl
scriptINFO: Package database updated
INFO: METADATA is out-of-date β you may not have the latest version of FITSIO
INFO: Use Pkg.update()
to get the latest versions of your packages
I'm interested in putting a little work into a higher-level interface for FITSIO, something akin to esheldon/fitsio. If you look at that package, I think the equivalent thing in Julia would be to define types for HDUs such as TableHDU
, ImageHDU
, and ASCIITableHDU
. This would allow you to define indexing operations on the data of an HDU, such as:
f = fits_open_file("data.fits")
f[1] # returns an HDU instance.
f[1][25:35, 10:20] # returns a subpatch of the data in the HDU
However, this design seems a little weird to me, because the HDU
types would have the same pointer as the main FITSFile
instance, and would have to move the current HDU to the correct extension before doing any operation. (Maybe that's not so bad?) It doesn't seem like you can have index notation without defining such types. I guess the alternative would be to have methods like
fitsread(f, 1, 25:35, 10:20)
Any thoughts?
PackageEvaluator.jl is a script that runs nightly. It attempts to load all Julia packages and run their tests (if available) on both the stable version of Julia (0.3) and the nightly build of the unstable version (0.4). The results of this script are used to generate a package listing enhanced with testing results.
Tests pass.
Tests fail, but package loads.
Tests pass.
means that PackageEvaluator found the tests for your package, executed them, and they all passed.
Tests fail, but package loads.
means that PackageEvaluator found the tests for your package, executed them, and they didn't pass. However, trying to load your package with using
worked.
This issue was filed because your testing status became worse. No additional issues will be filed if your package remains in this state, and no issue will be filed if it improves. If you'd like to opt-out of these status-change messages, reply to this message saying you'd like to and @IainNZ will add an exception. If you'd like to discuss PackageEvaluator.jl please file an issue at the repository. For example, your package may be untestable on the test machine due to a dependency - an exception can be added.
Test log:
>>> 'Pkg.add("FITSIO")' log
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
83 4541k 83 3806k 0 0 2815k 0 0:00:01 0:00:01 --:--:-- 2815k
100 4541k 100 4541k 0 0 3280k 0 0:00:01 0:00:01 --:--:-- 3278k
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for gfortran... gfortran
checking whether we are using GNU Fortran...
yes
cfitsio: == Adding wrapper support for GNU Fortran...
done
... truncated ...
a - zlib/infback.o
a - zlib/inffast.o
a - zlib/inflate.o
a - zlib/inftrees.o
a - zlib/trees.o
a - zlib/uncompr.o
a - zlib/zcompress.o
a - zlib/zuncompress.o
a - zlib/zutil.o
a - f77_wrap1.o
a - f77_wrap2.o
a - f77_wrap3.o
a - f77_wrap4.o
/bin/cp -a libcfitsio* /home/idunning/pkgtest/.julia/v0.4/FITSIO/deps/usr/lib
/bin/cp fitsio.h fitsio2.h longnam.h drvrsmem.h /home/idunning/pkgtest/.julia/v0.4/FITSIO/deps/usr/include
/bin/cp cfitsio.pc /home/idunning/pkgtest/.julia/v0.4/FITSIO/deps/usr/lib/pkgconfig
INFO: Installing BinDeps v0.3.0
INFO: Installing FITSIO v0.4.0
INFO: Installing SHA v0.0.2
INFO: Installing URIParser v0.0.2
INFO: Building FITSIO
INFO: Attempting to Create directory /home/idunning/pkgtest/.julia/v0.4/FITSIO/deps/downloads
INFO: Downloading file ftp://heasarc.gsfc.nasa.gov/software/fitsio/c/cfitsio3360.tar.gz
INFO: Done downloading file ftp://heasarc.gsfc.nasa.gov/software/fitsio/c/cfitsio3360.tar.gz
INFO: Attempting to Create directory /home/idunning/pkgtest/.julia/v0.4/FITSIO/deps/src
INFO: Attempting to Create directory /home/idunning/pkgtest/.julia/v0.4/FITSIO/deps
INFO: Directory /home/idunning/pkgtest/.julia/v0.4/FITSIO/deps already created
INFO: Attempting to Create directory /home/idunning/pkgtest/.julia/v0.4/FITSIO/deps/src/cfitsio
INFO: Changing Directory to /home/idunning/pkgtest/.julia/v0.4/FITSIO/deps/src/cfitsio
INFO: Package database updated
>>> 'using FITSIO' log
>>> test log
ERROR: type: ccall: expected Symbol, got Array{Any,1}
in include at ./boot.jl:245
in include_from_node1 at loading.jl:128
in process_options at ./client.jl:285
in _start at ./client.jl:354
in _start_3B_3500 at /home/idunning/julia04/usr/bin/../lib/julia/sys.so
while loading /home/idunning/pkgtest/.julia/v0.4/FITSIO/test/runtests.jl, in expression starting on line 11
>>> end of log
When I write to a new FITS file using a FITSHeader
object extracted from a previously opened FITS file, the comment block
COMMENT FITS (Flexible Image Transport System) format is defined in 'Astronomy
COMMENT and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H
is duplicated. For example:
julia> using FITSIO
julia> # Create a dummy file
julia> hdr = FITSHeader(["HELLO"], ["World"], [""]); data = rand(10,10);
julia> FITS("helloworld.fits", "w") do file
write(file, data, header=hdr)
end
shell> dfits helloworld.fits
====> file helloworld.fits (main) <====
SIMPLE = T / file does conform to FITS standard
BITPIX = -64 / number of bits per data pixel
NAXIS = 2 / number of data axes
NAXIS1 = 10 / length of data axis 1
NAXIS2 = 10 / length of data axis 2
EXTEND = T / FITS dataset may contain extensions
COMMENT FITS (Flexible Image Transport System) format is defined in 'Astronomy
COMMENT and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H
HELLO = 'World '
END
julia> # Read in the header of the dummy file
julia> hdr2 = FITS("helloworld.fits", "r") do file
read_header(file[1])
end
SIMPLE = T / file does conform to FITS standard
BITPIX = -64 / number of bits per data pixel
NAXIS = 2 / number of data axes
NAXIS1 = 10 / length of data axis 1
NAXIS2 = 10 / length of data axis 2
EXTEND = T / FITS dataset may contain extensions
COMMENT FITS (Flexible Image Transport System) format is defined in 'Astronom
COMMENT and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H
HELLO = 'World'
julia> # Write a new file with the old header
julia> FITS("helloagain.fits", "w") do file
write(file, data, header=hdr2)
end
shell> dfits helloagain.fits
====> file helloagain.fits (main) <====
SIMPLE = T / file does conform to FITS standard
BITPIX = -64 / number of bits per data pixel
NAXIS = 2 / number of data axes
NAXIS1 = 10 / length of data axis 1
NAXIS2 = 10 / length of data axis 2
EXTEND = T / FITS dataset may contain extensions
COMMENT FITS (Flexible Image Transport System) format is defined in 'Astronomy
COMMENT and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H
COMMENT FITS (Flexible Image Transport System) format is defined in 'Astronomy
COMMENT and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H
HELLO = 'World '
END
I also note that the string representation of the FITSHeader object cuts off the final "y" in the first COMMENT card.
I'm looking into getting WCS information out of FITS image files, and it seems like the preferred function to use is wcspih
, which, in WCSLIB.jl
at least, requires a raw ASCII FITS header. I think this can only be accessed with the now private Libcfitsio.fits_hdr2str
function.
I think this could also be done with wcsprm
, but I haven't been able to find clear enough documentation about exactly which header key values should go into which arguments to do this with confidence.
Do you have thoughts about whether there is a better way to do this, or whether maybe the raw header string should be available to users for this reason?
I see that FITSIO.jl has been released under the MIT license. However, the purpose of the code is to provide a link to the CFITSIO library, which is covered by the GPL (see http://heasarc.nasa.gov/docs/software/fitsio/c/f_user/node9.html).
Given the viral nature of the GPL, wouldn't this require that FITSIO.jl be released under the GPL too? The CFITSIO license states that "β¦any software that uses the CFITSIO library (which in turn uses the gzip code) must conform to the provisions in the GNU General Public License".
I know that different opinions exist on this topic (see http://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works), but I wanted to know the author's position regarding this delicate issue.
(By the way: I am not a fan of the GPL, as I hate its viral nature. As a matter of fact, http://heasarc.nasa.gov/docs/software/fitsio/c/f_user/node9.html states that CFITSIO has been released under the GPL because it links to some GPL'ed code from zlib and AIPS. But I think it is important to fix this kind of issues.)
I notice there's no integration with Images.jl here, and I'm curious about the reasons. If Images.jl doesn't actually offer anything of value to you, what would it take to make it useful? (I'm not saying I expect that it already has every algorithm you'd ever need, but I'd be equally surprised if there's nothing of value---if so, that's clearly a deficiency in Images.jl.) If Images.jl's I/O architecture isn't compatible with your needs, again it would be interesting to know what would need to be done to make it work. Images.jl is currently being used by the computer-vision and biomedical imaging folks, but I'm not aware of any astronomy people, and it would be great to make sure your needs are also met.
For I/O integration, see docs here:
https://github.com/timholy/Images.jl/blob/master/doc/extendingIO.md
The hope would be that a couple of stub functions in a file starting with using FITSIO
would allow easy integration. If you need more sophisticated control over I/O than Images currently offers, well, that would be something we could talk about.
Now that Julia v0.7-alpha is out the door, we should be looking to update FITSIO.jl for the latest version. However, Julia v1.0 is supposed to be unchanged from v0.7 (just dropping deprecation warnings). Therefore, this seems to be a sensible place to drop support for earlier versions and focus on 1.0+, which should hopefully be a stable platform for a number of years.
As an added bonus, FemtoCleaner will do a lot of the work for us if we're willing to drop support for v0.6 and lower.
Personally, I think we should tag one more version that includes the latest changes on v0.6 and then push forward on v0.7 only.
Thoughts?
Now that JuliaLang/julia#24960 has been merged, it's possible to do fancy things with a.b
syntax. I think it could make sense to use this feature in FITSIO.jl
, so that fields can be accessed with the more natural syntax fits.field
, rather than fits[:field]
. What do you think?
It should be easy to deprecate the old syntax in favor of the new one, however I fear that all this will require Julia 0.7.
Hello,
I have a parallel code that exploits the module SharedArrays
but when I try to write a SharedArray
into a FITS file, I get the following error message:
ERROR: LoadError: MethodError: no method matching write(::FITS, ::SharedArray{Float64,1})
Closest candidates are:
write(::FITS, !Matched::Array{String,1}, !Matched::Array{T,1} where T; units, header, hdutype, name, ver, varcols) at /home/users/federico.incardona/.julia/packages/FITSIO/BavHZ/src/table.jl:361
write(::FITS, !Matched::Array{T,N} where N; header, name, ver) where T at /home/users/federico.incardona/.julia/packages/FITSIO/BavHZ/src/image.jl:166
write(::FITS, !Matched::Dict{String,V} where V; units, header, hdutype, name, ver, varcols) at /home/users/federico.incardona/.julia/packages/FITSIO/BavHZ/src/table.jl:409
...
Stacktrace:
[1] top-level scope at none:0
[2] include at ./boot.jl:326 [inlined]
[3] include_relative(::Module, ::String) at ./loading.jl:1038
[4] include(::Module, ::String) at ./sysimg.jl:29
[5] exec_options(::Base.JLOptions) at ./client.jl:267
[6] _start() at ./client.jl:436
in expression starting at /gpfs/home/users/federico.incardona/julia_parallel_prova.Jl:31
So, is it possible to add a method to make FITSIO
compatible with SharedArrays
?
Would it make sense to make the HDU
concrete types parametric? E.g., ImageHDU{T, N}
, with T
the data type and N
the number of dimensions of the underlying data array. This should also make read(...)
type stable.
Ideally we could do something similar for the tables, but it's less clear how to encode the information, as they depend also on the specific column
Hello,
I report here an issue I had with FITSIO installation and reported to Stackoverflow. My Julia version seems incompatible with FITSIO since it automatically installed the wrong FITSIO package. I had to manually force the URL to download the correct one. Maybe the problem comes from my Julia version, I just let you know the issue.
Kind regards
I have had problems with reading the header of an M31 Andromeda FITS file - which was part of my wife's S177 UK Open University Astronomy project - using the HIGH level routines
The file is from the http://www.spacetelescope.org (NASA/ESA Hubble Space Telescope) so has reasonably parentage :
http://www.spacetelescope.org/static/projects/fits_liberator/datasets/m31/f001a066.zip
using FITSIO
cd ("S177")
f001a = FITS("f001a066.fits")
file: f001a066.fits
mode: r
extnum exttype extname
1 image_hdu
size(f001a[1])
(7055,7055)
data = read(f001a[1]);
data[7055,7055]
29976
header = readheader(f001a[1])
ERROR: couldn't parse keyword value: "1.9511305786508E+00,"
in parse_header_val at /Users/malcolm/.julia/v0.3/FITSIO/src/hdutypes.jl:161
in readheader at /Users/malcolm/.julia/v0.3/FITSIO/src/hdutypes.jl:204
The keyword value has a trailing ',' which throws the error in parse_header_val
Using the LOW level API gave no problems:
f001 = fits_open_file("f001a066.fits")
n = fits_get_hdrspace(f001)[1]
for i = 1:n
println(fits_read_keyn(f001,i))
end
Looking at the header from a LOW level data dump, the problem is with the SKEW value but I suspect it is actually the entry above which has no key or value, just a comment, which I suspect is the real culprit
("CROTA1","1.9373114911858E+00","Rotation angle of first axis (deg)")
("CROTA2","1.9373114911858E+00","Rotation angle of second axis (deg)")
("","","Warning: CROTA2 is inaccurate due to considerable skew")
("SKEW","1.9511305786508E+00,","1.9234924037208E+00 /Measure of skew")
A work around in the parse_header_val routine (my hack-- I am a reformed Perl programmer after all) was :
function parse_header_val(my_val::String)
if length(my_val) == 0 return "" end
val = (my_val[end]==',') ? chop(my_val) : my _val
try
return int(val)
etc....
But clearly a fix is better in reader header() to ensure that the values don't have trailing ',' or other nasty characters to begin with.
Currently it is not possible to create an empty fits file, one with minimal header information, something along the lines of what's presented here: esheldon/fitsio#164 (comment). This would be a nice feature to have.
Hi, we were following the documentation at https://julia-fitsio.readthedocs.io/en/latest/. The last code block is supposed to generate a Dict()
. However, we get
julia> data = ["col1"=>[1., 2., 3.], "col2"=>[1, 2, 3]];
julia> write(f, data)
ERROR: MethodError: no method matching bitpix_from_type(::Type{Pair{String,Array{Float64,1}}})
Closest candidates are:
bitpix_from_type(::Type{UInt8}) at /home/hsgg/.julia/v0.6/FITSIO/src/libcfitsio.jl:140
bitpix_from_type(::Type{Int16}) at /home/hsgg/.julia/v0.6/FITSIO/src/libcfitsio.jl:140
bitpix_from_type(::Type{Int32}) at /home/hsgg/.julia/v0.6/FITSIO/src/libcfitsio.jl:140
...
Stacktrace:
[1] fits_create_img(::FITSIO.Libcfitsio.FITSFile, ::Type{Pair{String,Array{Float64,1}}}, ::Array{Int64,1}) at /home/hsgg/.julia/v0.6/FITSIO/src/libcfitsio.jl:735
[2] #write#3(::Void, ::Void, ::Void, ::Function, ::FITSIO.FITS, ::Array{Pair{String,Array{Float64,1}},1}) at /home/hsgg/.julia/v0.6/FITSIO/src/image.jl:168
[3] write(::FITSIO.FITS, ::Array{Pair{String,Array{Float64,1}},1}) at /home/hsgg/.julia/v0.6/FITSIO/src/image.jl:166
[4] macro expansion at ./REPL.jl:97 [inlined]
[5] (::Base.REPL.##1#2{Base.REPL.REPLBackend})() at ./event.jl:73
We are using julia-0.6.0.
I have a TLONG
that I would like to write to the header using Libcfitsio.fits_write_key
(the function is mirroring a C routine so I want to use the Libcfitsio interface). At the moment the function only accepts floats and strings (see the link below), but it naively looks like it might have been written with a wider signature in mind.
Lines 347 to 358 in 8f53836
Edit: grammar and typos
Is the current version v0.11.0 of FITSIO supposed to work under Julia 1.0?
I get the following error when starting FITSIO for the first time:
[ Info: Precompiling FITSIO [525bcba6-941b-5504-bd06-fd0dc1a4d2eb]
ERROR: LoadError: syntax: extra token "ImageHDU" after end of expression
Stacktrace:
[1] include at ./boot.jl:317 [inlined]
[2] include_relative(::Module, ::String) at ./loading.jl:1038
[3] include(::Module, ::String) at ./sysimg.jl:29
[4] top-level scope at none:2
in expression starting at /Users/Bob/.julia/packages/FITSIO/WueGk/src/FITSIO.jl:54
copy_section(hdu, dest, range...)
has an argument order reversed from the standard order, where the destination is the first argument. This would be easy to switch and deprecate the old version.
Perhaps the name should be copy_section!
or just extend Base.copy!
. This is slightly different than Base.copy!
because dest::FITS
and hdu::ImageHDU
are not the same types of things.
This issue is being filed by a script, but if you reply, I will see it.
PackageEvaluator.jl is a script that runs nightly. It attempts to load all Julia packages and run their test (if available) on both the stable version of Julia (0.2) and the nightly build of the unstable version (0.3).
The results of this script are used to generate a package listing enhanced with testing results.
The status of this package, FITSIO, on...
'No tests, but package loads.' can be due to their being no tests (you should write some if you can!) but can also be due to PackageEvaluator not being able to find your tests. Consider adding a test/runtests.jl
file.
'Package doesn't load.' is the worst-case scenario. Sometimes this arises because your package doesn't have BinDeps support, or needs something that can't be installed with BinDeps. If this is the case for your package, please file an issue and an exception can be made so your package will not be tested.
This automatically filed issue is a one-off message. Starting soon, issues will only be filed when the testing status of your package changes in a negative direction (gets worse). If you'd like to opt-out of these status-change messages, reply to this message.
Hi!,
If I create a header with the reserved key BUNIT
and I save the file,
the key BUNIT
is not written in the header of the file. Am I wrong somewhere ?
Thanks in advance
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.