I'm trying to use the READFITS() function on IDL 8.3 on Mac 10.9.3
My input on the IDL promt:
readfits('image.fits',h, /EXTEN, /SILENT)
Result:
readfits('image.fits',h, /EXTEN, /SILENT)
^
% Syntax error.
*note: the '^' is below '/EXTEN'
Maybe it will help, so here is a link to the IDL help page on using READFITS() --> http://www.exelisvis.com/docs/readfits.html
I tried using the brackets like they show on that help page, but it still didn't work, so I'm stuck now. Didn't know if anyone here has experience reading .fits files in IDL.
ok, so it turns out the readfits procedure isn't included in IDL's original library, so I just had to download AstroLib (contains lots of useful astronomy procedures - including Readfits). The original syntax then worked.
I'm using IDL 8.2.2 on OS X 10.9.4.
Try keeping it simple first. Do these work?
readfits('image.fits')
readfits('image.fits', header)
Next try this:
readfits('image.fits', header, EXTEN_NO=0)
I suspect you really want extension number 0, not 1. See (e.g.) http://www.stsci.edu/documents/dhb/web/c02_datafiles.fm2.html.
Related
We use a linter (for Golang) that run through a Github Actions workflow every time we open or update a Pull Request on our repository.
It recently started to return the following error:
File is not `gofmt`-ed with `-s` (gofmt)
After what happened in this other PR to the file pkg/api/api/go.
(EDIT: link added to evaluate and eventually reproduce the error)
Evidences:
I would like to understand what was the source of this error, as well as how to resolve it?
Source of the error
It seems this error can be returned when the file is not properly formatted according to Go rules.
For example: If you accidentally used tab indentation rather than spaces.
EDIT: blackgreen's answer gives more accurate details about the source of the error
How to resolve it
You can use the following Go command:
gofmt -s -w <path_to_file>.go
... then commit the code.
Note that in my case: gofmt -w pkg/api/api.go was enough to resolve the problem (without the -s flag, which I found strange as the error specifically asked for the -s).
Source 1 + Source 2
The -s flag in gofmt has nothing to do with formatting. It's about simplifying the code:
Try to simplify code (after applying the rewrite rule, if any).
The warning you see comes from the linter golangci-lint. Since you claim to have fixed the error by running gofmt -w, the presence of the hint "with -s" may be due to this bug: https://github.com/golangci/golangci-lint/issues/513.
The linked issue was fixed in 2019 and released with v1.17.0. You might want to check if your pipeline is using an older version.
Assuming that your file pkg/api/api.go triggered the warning just because it was not formatted, gofmt -w solves the issue because -w overwrites the file:
If a file's formatting is different from gofmt's, overwrite it with gofmt's version.
RStudio : 0.98.994
OS: Microsoft Windows 7 Ultimate Edition, 64-bit Service Pack 1
MiKTeX: 2.9.4503
Hi,
I get the following error when I try to knit a PDF document.
pandoc.exe: Error producing PDF from TeX source.
This is pdfTeX, Version 3.1415926-1.40.11 (MiKTeX 2.9)
pdflatex: The memory dump file could not be found.
pdflatex: Data: pdflatex.fmt
I also tried devtools::install_github('rstudio/rmarkdown') but was still getting an error when I added 'fig.align='center' to a ggplot2 plot in my document. It would work as HTML, but not as PDF.
After seeing isomorphismes's post I clicked on the gear symbol next to the knit PDF button, then under the advanced tab I changed the LaTeX Engine to xelatex. After that I no longer received the error message and my PDF document was created without problems.
Thank you.
I found the answer here: http://rmarkdown.rstudio.com/tufte_handout_format.html#comment-1582377678
The problem is that you need to add \usepackage[utf8]{inputnc} to the preamble of the tufte-handout.tex file in the rmarkdown package.
This was fixed here: https://github.com/rstudio/rmarkdown/commit/484d5b8e903e0e0c75c82f707efa35f9fd9a52b0
To update your rmarkdown package, you can use directly in the RStudio command line
devtools::install_github("rstudio/rmarkdown")
None of the above worked for me when knitting to PDF (and I wanted to keep the scientific notation). The problem was that latex code was generated that included "\times" without the necessary bracketing by $. In the markdown I simply bracketed the inline R code with $'s, like so:
$p = `r signif(cor.HF$p.value, 2)`$
Voila!
happy to share with you my solution.
---
title: "Untitled"
author: "-----"
date: "21/6/2017"
output:
pdf_document:
latex_engine: xelatex
---
I was able to fix it in my case. I experienced that error when generate PDF from Rmd if I added float values into a text that R tried to display as a scientific notation. For example, instead of "520274.72" it tried to add text "5.2027472 e10-5" which leads to latex code \textbf{5.2027472\times 10\^{}{5}} that was not compiling. I fixed it by wrapping it with format(....,scientific=FALSE).
replace
r round(txn_pd,2)
with
r format(round(txn_pd,2),scientific=FALSE)
I had the same problem and devtools::install_github('rstudio/rmarkdown') didn't work for me. I needed to
rmarkdown::render('in.md',
output_format=pdf_document(latex_engine='xelatex')
)
with the novel command (use xelatex) on its own line.
I encountered this problem while I was trying to add an in-line r code r test1$p.value, which is a very small p-value from t test. The error information is as following:
> ! Missing $ inserted.
> <inserted text>
> $
>l.147 9.0044314\times
>
>pandoc: Error producing PDF
>Error: pandoc document conversion failed with error 43
>Execution halted
I think the problem is the pdflatex engine has a trouble in displaying the small p-value in exponential notation.
I solved the problem by clicking on the gear symbol next to the knit button, then under output options, advanced tab I changed the LaTeX Engine to lualatex, or you can just report the p-value as p < 0.001.
If you are using inline values from your R code which are in the scientific format (too small or too big), format them like:
replace r x
with r format(x, digits=n) where n is whatever.
for me it was because on my headers I was putting + signs. For example gene + treatment. This errors but when I removed it, it works.
In my case it was solved simply by editing the author field in:
---
title: "Document Title"
author: '-----'
date: "21-03-2017"
output: pdf_document
---
the default '-----' would yield the error, but replacing it with anything (for example 'Juan') solved the issue.
I just ran into this problem and already solved it. I didn't use any code as other people did in their posts.
I will assume that you have installed all these basic stuff: R, RStudio, the rmarkdown package, the knitr package, and the MikTex basic installation (I know this is very basic, but I want those first timers know that you need these stuff to make this happen).
If you run into this problem, go to R GUI, upgrade the rmarkdown package and it should work then. Note that if you change the LaTeX Engine to xelatex as the poster of the highest vote did, it may not work for you, at least it did not for me. I leave my latex engine as it is (pdflatex).
I had a similar issue. My solution was to remove the "leading" period in the YAML title argument:
Does not work:
---
title: “1. Title”
output: pdf_document
---
output file: example.knit.md
! Argument of \reserved#a has an extra }.
\par l.79 \end{enumerate}}
pandoc: Error producing PDF Error: pandoc document conversion failed
with error 43 Execution halted
Works:
---
title: “1 Title”
output: pdf_document
---
I did try to use the xelatex engine but still, I got the error that xetex.def is not found. This is another to work around.
output:
pdf_document:
keep_tex: yes
latex_engine: xelatex
Then open .tex file in your TEX editor and build pdf as usual.
I faced a similar issue. In my case, the error occurred because of putting a percentage inside the $ sign.
Like this,
$95%$, I removed the % sign, and everything worked fine.
I've been using vim over ssh to work for a week or two now and all has been going great. Today I decided to add in some syntax highlighting, autocomplete, and some other general plugins. Set up vundle and went to work.
My current .vimrc can be found at https://github.com/scottopell/dotfiles/blob/master/.vimrc
I have cloned my vimrc and vim files onto my local ubuntu desktop and vim runs exactly as expected, no slowness on any files that I can find. Same plugins and same vimrc and no slowness on ruby files.
update
I can reproduce this issue with the following .vimrc
syntax on
and an empty ~/.vim folder.
However, vim on this vps is very slow with ruby/haml files. Much moreso ruby files. When I open any ruby file, startup takes about 2 seconds (timed with --startuptime). With a comparable length haml file, its about .5 seconds. This slowness isn't just on startup either, moving around and editing the file are both painfully slow.
Haml/erb(they are basically the same)
268.818 000.005: before starting main loop
848.871 580.053: first screen update
Ruby
199.613 000.004: before starting main loop
2937.859 2738.246: first screen update
Without syntax highlighting on the same ruby file as above
149.047 000.004: before starting main loop
152.912 003.865: first screen update
I have tried using mosh(http://mosh.mit.edu) and it doesn't help. not really relevant anymore
As you can see in my .vimrc file, I have tried a few different solutions to this problem.
I have tried running with all plugins disabled (I moved them all from ~/vim/bundle/PLUGINNAME to ~/vim/bundle/disabled/PLUGINNAME, is this correct?), set ruby path, set foldlevel to manual, disabled my colorscheme, nothing helps. see edit3
I can post the full startupttime log for any file if that will help.
I have tested a few other languages(php, c, python, vimL) and none experience any slowdown.
EDIT: Just to clarify, I am running an ssh session with ssh user#server then once inside the server I am doing vim file.rb.
EDIT2: I just tried accessing the server directly and the slowness persists without ssh, I have updated to reflect that this isn't a problem with ssh.
EDIT3: I can reproduce the issue with a .vimrc file that contains the single line syntax on with an empty ~/.vim folder
EDIT4 I uninstalled my compiled version of vim and any versions that I may have installed through apt, manually removed all vim stuff from my system, and I can run vim with vim -u NONE /path/to/file.rb then do :syn on and the issue will be there. The file in question is a rails controller, but like I've said, I can recreate it to some degree with most any file, but rails controllers see to be the worst.
The solution to this problem turned out to be the regex engine that vim uses.
The speculation on #vim on freenode is that the ruby syntax files use something that is slower on the new regex engine.
Any version older than and including Vim 7.3.969 has the old regex engine.
Add in set re=1 to your vimrc to force the old regex engine on any version newer (and don't forget to reload the file you're currently editing with :e).
Thanks to Houl, Dolio and dmedvinsky from #vim for help figuring it out.
I haven't had a chance to try the absolute latest version, there was a commit last night that may help with this issue. I will update this if I get the chance to try the bleeding edge version again.
You should set this tw options in your vimrc:
set ttyfast
set lazyredraw
If this is not solving your problem try to start vim without your vimrc to be sure that none of your current settings are screwing it up.
vim -u NONE
Two things that will drastically help speed up Ruby syntax highlighting are disabling cursor line and relative number for Ruby (if you use those).
I have the following in my .vimrc:
" Ruby is an oddball in the family, use special spacing/rules
if v:version >= 703
" Note: Relative number is quite slow with Ruby, so is cursorline
autocmd FileType ruby setlocal ts=2 sts=2 sw=2 norelativenumber nocursorline
else
autocmd FileType ruby setlocal ts=2 sts=2 sw=2
endif
I'm using vim 7.4.52 and none of these solutions worked for me.
According to this github comment on the issue (https://github.com/vim/vim/issues/282#issuecomment-169837021), foldmethod=syntax is responsible for the slowness.
Adding this to my .vimrc finally fixed it!
augroup ft_rb
au!
" fix the SLOOOW syntax highlighting
au FileType ruby setlocal re=1 foldmethod=manual
augroup END
Try setting your ruby path explicitly in your vimrc:
let g:ruby_path="/usr/bin/ruby"
see UPDATE at the bottom.
this may be helpful as a workaround -
i am using vim version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jan 2 2014 19:40:46)
Included patches: 1-52
it is the stock version from
Linux Mint 17.1 Rebecca.
the php.vim syntax file is not version'd that i can see, but it sez last edit'd 28 aug 13.
it isn't a ruby project, but when editing a large php class file (
$ php -w test.inc | wc
2 2410 19220
) i note significant delays near the top of the class, but not above or below the class, and, notably, not toward the bottom of the class. as i attempt to insert new text near the bottom of the class, delay is minimal and seems to be proportional to the line number inside the class. "minimal" means almost instantly, "significant" means 1 to 1.5 seconds per character.
the file is approx 1800 lines with approx 500 lines of legit php and 1300 lines of comments and doc. the class begins at approx line 30 and ends at approx line 1700. it is conceded it's a bit large, but well documented :-\
if i insert
class dummy { }
in front of the original "class originalName {",
there is no delay anywhere in the file. this unsightly kluge permits vim/gvim to regain its responsiveness and could be considered a workaround. note no linefeed between the two, just
class dummy { } class originalName {
it can even be comment'd out:
/*class dummy {}*/class originalName {
additional info:
during this test, the plugins directory was moved.
with "set syntax=off", the problem completely disappears. this is NOT a fix.
setting the regular expression engine with
set regexpengine=1 (or any other number)
does not appreciably change the results.
based on these results, i would suspect the regular expression engine as well. my point is that diddling a bit with the syntax in ruby files may lead to a workaround.
UPDATE:
i have found that the issue is "caused" by setting php_folding to 1 (enabled). the vimrc i THOUGHT i was using was not, but at least some of the mystery is solved due to that mistake. a simple vimrc like this will induce the problem (for me, as least):
:syntax enable
:let php_folding = 1
this means my issue is totally unrelated to the ruby issue, but there may be a similar thing going on with the ruby.vim file. maybe not.
apologies for the deflection.
I tried most of these solutions but what ended up working for me the best was removing any plugins associated with airline.
I am trying to compile PHP on my Mac OS X 10.8 and I am getting the following problem:
In file included from /Users/ryan/Downloads/php-5.4.5/ext/phar/util.c:23:
ext/phar/phar_internal.h:223:19: error: invalid token at start of a preprocessor
expression
# if SIZEOF_SHORT == 2
^
I'm not sure why this error is occurring as this looks fine to me. I have opened the header file and could make changes if not or remove the if all together as I know what my system should be, but I was wondering if this is the proper approach to this problem.
It looks like SIZEOF_SHORT expands to no tokens. You should investigate where SIZEOF_SHORT is being #defined (this may be on the command line via -DSIZEOF_SHORT=) and fix that to provide the right value.
Alternatively, you could use this:
#include "limits.h"
/* ... */
#if SHRT_BIT == CHAR_BIT * 2
I didn't really find a solution to this problem, but I removed the if's and left behind the line that would be processed anyway and the program compiled just fine. I really don't know what was wrong with this file.
I am trying to build Win32::Daemon by myself. The reason I not use CPAN is because I want to dig deeper into the working of Perl modules. In the end I hope to come up with a solution for another problem by seeing this working (not of importance here).
I would see 3 options to build the module: cygwin, mingw, microsoft compiler (cl)
On MinGW it reports that it is not supported (simple if in the Makefile.PL) which expands to more errors once I modify the check to match MinGW
On Cygwin it complains about tchar.h which, as I found out, is a Windows header (MinGW does have it).
But my real goal anyway is building it with the MS compiler, so while any compilation that does not require any special libs (like it would do with cygwin I suppose) will more.
So now here goes my nmake output from running just name /f Makefile:
NMAKE : fatal error U1073: "C:/Program" could not be created.
Stop.
I roughly translated the error message from german, but the statement is simple.
What I see here seems to be a path problem (probably the spaces). I also notice the forward slash. The Makefile was created by the Makefile.PL script (I am using Active Perl v5.12.1):
use strict;
use warnings;
use Config qw(%Config);
use ExtUtils::MakeMaker;
unless ($^O eq "MSWin32" || $^O eq "cygwin") {
die "OS unsupported\n";
}
require Win32;
my %param = (
NAME => 'Win32::Daemon',
VERSION_FROM => 'Daemon.pm',
DEFINE => '-DPERL_NO_GET_CONTEXT',
OBJECT => 'CCallbackList$(OBJ_EXT) CCallbackTimer$(OBJ_EXT) Constant$(OBJ_EXT) CWinStation$(OBJ_EXT) Daemon$(OBJ_EXT) ServiceThread$(OBJ_EXT)',
XS => { 'Daemon.xs' => 'Daemon.cpp' },
);
$param{INC} .= ' -EHsc' if $Config{'cc'} =~ /^cl/i;
$param{NO_META} = 1 if eval "$ExtUtils::MakeMaker::VERSION" >= 6.10_03;
WriteMakefile(%param);
sub MY::xs_c {
'
.xs.cpp:
$(PERL) -I$(PERL_ARCHLIB) -I$(PERL_LIB) $(XSUBPP) $(XSPROTOARG) $(XSUBPPARGS) $*.xs >xstmp.c && $(MV) xstmp.c $*.cpp
';
}
I don't know much about the MakeMaker but I don't see anything here that I could fix and would expect that it boils down to fixing the Makefile itself by hand. I tried a couple of things like quoting but nothing helped.
The thing is, I am used to problems like this when building on Windows, but normally this is for tools that were created for Unix. This one is explicitly ONLY Windows and so I would expect it to work out of the box. So I figure that I am doing something wrong.
Any help on where to find the solution?
Thanks in advance.
Edit/Addition: I tried this on another Win7 machine with Active Perl 5.16.x and it worked like a charm. I looked at the different output from this machine and the current one which fails when running perl Makefile.PL and I recieve the following output:
... Detected uninstalled Perl. Trying to continue.
Unable to find a perl 5 (by these names: C:\Program Files\Perl64\bin\perl.exe perl.exe perl5.exe perl5.12.1.exe miniperl.exe, in these dirs: . [...] C:\Program Files\Perl64\site\bin C:\Program Files\Perl64\bin [...])
Have \progra~1\perl64\lib
Want \temp\perl---please-run-the-install-script---\lib
Writing Makefile for Win32::Daemon
I truncated the output. Now please someone explain to me: Why can I run perl Makefile.PL or perl -v but it does not find my Perl in the exact directory it is in? I reinstalled it but it did not work...
Okay I finally seem to have solved this after hours of searching. The problem lies within multiple issues.
The first command of "uninstalled perl" does not make any sense to be, but you can fix it, by supplying perl Makefile.PL PERL_SRC="C\:Program Files\Perl64". Warning: This did not work in a command shell for me, I had to use powershell, because he would not treat the path correctly. You maybe need to juggle with this a bit. Note: In the end I fixed it by installing the original Active Perl, not the one provided by my installer (company software distribution)
Now to the issue of not finding perl: This is a problem with spaces in the path. I fixed this (seemingly) by creating a symlink without spaces. Now perl Makefile.PL does not throw any errors, but nmake -f "Makefile" failed. So the solution really was: Do not have spaces in your perl-path! This sucks, and quite frankfly in 2012 this shouldn't be a problem any more but here you go.
Thanks for all the effort everyone put in, this was a tough one to solve.