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.
Related
I'm using Ragel 6.10 with Go. I'm sure it's likely an issue with my code but I'm getting some weird errors when I try to use a stack with a scanner block. I'm trying to setup bracket matching and my code looks roughly like this;
ObjectValues := |*
# other stuff
'}' => { fret; };
*|
main := ('{' #{fcall ObjectValues;})*;
Looking at page 46 in the guide it looks like this should be possible. When I run Ragel ragel -G2 -Z main.rl. I get the following error when I try to compile (it only happens for -G2 FSM generation);
graphql_collections.rl:47[/Users/nathanfisher/workspace/go/src/github.com/nfisher/gir/graphql_collections.go:325:2]: syntax error: unexpected goto at end of statement
graphql_collections.go:60[/Users/nathanfisher/workspace/go/src/github.com/nfisher/gir/graphql_collections.go:60:1]: label _again defined and not used
Commenting out the fret line removes the error and warns postpop and prepush are unreachable.
The full code is here;
https://github.com/nfisher/gir/blob/broken/graphql_collections.rl#L47
A working minimal test-case is here;
https://gist.github.com/nfisher/649ca816f82bb3ccd7164331ac2324ac
Error for test-case;
main.rl:13[/Users/nathanfisher/workspace/go/src/github.com/nfisher/gir/command/runner/main.go:119:2]: syntax error: unexpected goto at end of statement
main.go:59[/Users/nathanfisher/workspace/go/src/github.com/nfisher/gir/command/runner/main.go:59:1]: label _again defined and not used
It looks like this is an issue relating to Ragel's generated code in v 6.10. Using the HEAD of ragel-6 branch fixes the issue. Thanks to Adrian Thurston for being super responsive/helpful via Twitter. :)
Reformatting the code from this;
To this fixes the error;
TL;DR
How to find where exactly vim or nvim error started (which file?) when I'm interested in fixing the actual issue and not just removing the bad plugin? Anything better than strace and guesswork to find the error origin?
Issue
I often add a plugin to my vim or nvim config and end up getting errors on hooks (buffer open, close, write):
"test.py" [New] 0L, 0C written
Error detected while processing function 343[12]..272:
line 8:
E716: Key not present in Dictionary: _exec
E116: Invalid arguments for function get(a:args, 'exec', a:1['_exec'])
E15: Invalid expression: get(a:args, 'exec', a:1['_exec'])
The problem is, I have no idea where those come from, only get some line number of unknown file and I know it's not my vim/nvim config file.
Somewhere, you have a plugin that has defined a dictionary with anonymous-functions (check the help related to this tag).
For the curious ones, it's done this way:
let d = {}
function! d.whatever() abort
throw "blah"
endfunction
When you execute this function, you'll get the kind of error you're currently observing. That's why I stopped working this way to prefer:
let d = {}
function s:whatever() abort
throw "blah"
endfunction
let d.whatever = function('s:whatever') " a workaround is required for older versions of vim
" At least this way I'll get a `<SNR>42_whatever` in the exception throwpoint, and thus a scriptname.
That's the why. Now, back to your problem, AFAIK, the only things you'll be able to know are the two functions that have been called:
in line 12 of :function {343}, you've called
:function {272} which contains an error at line 8.
Thanks to these two commands (may be prefixed with :verbose, I don't remember exactly), you'll get the source code of the two functions, which you should be able to use in order to grep your plugins to know where it appears.
how to fix Line is too long error in a ruby file without ignoring it and not introducing new errors.
I have tried giving the extra character in the next line using IDE. It is introducing new errors like 'Ternary operators must not be nested. Prefer if or else constructs instead.'
Rubocop already suggested the way to fix this error. Let me repeat it here. Assuming you have a very long line that reads:
variable = long_condition ? true_clause : false_clause
change it to:
variable = if long_condition
true_clause
else
false_clause
end
Other way would be to instruct rubocop to [temporary] ignore this error by running from the very project directory:
rubocop --auto-gen-config
Or, as last but not the least chance, update your .rubocop.yml file to increase a line length within a respective rule.
Rubocop tells you what to do, just follow its advice.
Also, have a look at the ruby styleguide, which explains all the rubocop rules in detail.
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.
I'm using MSVC++ to program a simple window, and I included a resource file for a menu along the lines of:
MYMENU MENU DISCARDABLE
//etc.
and I created a header file "resourcedef.h" with definitions like
#define ID_MYMENU_FILE_CLOSE 1002
I can include it in my main.cpp file without error, however, when I include it in the resource file, I get the error
.\resourcedef.h(9) : fatal error RC1004: unexpected end of file found
(resourcedef.h is exactly 9 lines long). When I add a newline the the end of the .h,
//lines 1 - 8
#define ID_MYMENU_FILE_OPEN 1001
So that there is a tenth blank line (that doesn't appear on SO), it compiles fine. If I put anything on the tenth line, even a comment, the compiler gives me an error. Does anyone know what causes this and how I can fix it?
It's a bad idea to omit the trailing newline at the end of a text file - there are many tools that will fail to work properly unless it's there. (Some text editors will even warn you that's it's missing.)
Trailing newlines are standard behaviour for text files - why not go with the flow and just put one there. Everybody else does. 8-)
Long ago, MSVC++ at version 2 or so (1994-ish) would not handle "partial" lines at the end of the file properly. For example:
header.h
#ifndef __HEADER_H
#define __HEADER_H
void foo();
#endif // <-- no newline here
main.cpp
#include "header.h"
#include "other.h"
In this situation, the preprocessor would see the following text after resolving includes:
#ifndef __HEADER_H
#define __HEADER_H
void foo();
#endif#include "other.h"
The bug was that the last line would run together as shown above, and the "other.h" file would not be included. With the IDE at that time, it was easy to accidentally create a file with no trailing newline and run into the above situation.
Fortunately, this bug has long since been fixed. It looks like you've found one of the situations where the compiler warns that it doesn't expect to encounter the end of the file in the middle of a line. This is generally regarded as a good thing.