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.
First off, I know there are a lot of questions regarding this error and I have checked them all, mine is not solved using any of their solutions however.
I am working for the first time with Puppet / Ruby and am having the following issue.
I created this function:
module Puppet::Parser::Functions
newfunction(:phpversion, :type => :rvalue) do
%x["/usr/bin/php -r 'echo PHP_MAJOR_VERSION . \".\" . PHP_MINOR_VERSION;'"]
end
end
And when I call it in my manifest file using:
$phpversion = phpversion()
It throws, when I execute the agent, the error "Error: Could not retrieve catalog from remote server: Error 400 on SERVER: wrong number of arguments (1 for 0) at /etc/puppetlabs/puppet/modules/x/manifests/somefile.pp:123 on node foo.example.bar"
I tried adding |args| after the do statement and removing :type but it keeps throwing the same error. when I use $phpversion = phpversion it just thinks its a text string instead of a function (which I expected, but tried anyway).
Any help would be greatly appreciated.
If you're trying to get the version of php, it'd probably be easier to do it as a fact:
Facter.add(:phpversion) do
setcode do
if Facter::Util::Resolution.which('php')
Facter::Util::Resolution.exec('/usr/bin/php -r 'echo PHP_MAJOR_VERSION . \".\" . PHP_MINOR_VERSION;'"').lines.first.split(/"/)[1].strip
end
end
end
Put this a directory lib/facter/ in your module, then reference it in your manifest as $::phpversion
I am new to ruby. I have created a helper method file for my watir scripts. When I try to run the script it hits this line:
require "C:/Sites/common/helper_methods"
and throws this error message:
C:/Sites/common/helper_methods.rb: C:/Sites/common/helper_methods.rb:1387: Invalid break (SyntaxError)
so I am not sure what the error means.
I have searched for an answer but can not find one that helps me figure out the message.
Any help would be appreciated.
Joe
Hi Paul,
Here is the method before 1387
#Write Subject Lines to file
def add_subject_line_to_file(s)
project_path = Dir.pwd
fileNamePath = File.join(project_path,'data_files','multi_add_discussion_files','multi_add_discussion_headers.txt')
#Writing to new file
open(fileNamePath,'a+'){ |f|
f << "#{s}\n"
}
end
which might be the problem
the method after 1387
#The following method will validate text at on the page not in a specific location
def text_validation(rt)
#Validate comment displays
if #browser.text.include? rt
#Response
response = "PASS!!! The following user comment was found [ #{rt} ]."
write_to_file(response)
else
#Response
response = "FAIL!!! The following user comment was NOT found [ #{rt} ]."
write_to_file(response)
end #End of Validate comment displays
end
The line:
C:/Sites/common/helper_methods.rb:
C:/Sites/common/helper_methods.rb:1387:
Invalid break (SyntaxError)
means there's an error parsing (SyntaxError) on line 1387 of helper_methods.rb ( ...helper_methods.rb:1387).
It's possible that the error occurs much earlier but the interpreter is only able to notice it at line 1387. Posting the lines around line 1387 may help diagnose further.
1378 is a lot of lines to have in one file. You may want to think about breaking those methods up into related hunks and include only the portions you need. Doing this would also help find the error if you could require 5 or 6 you know the error is in the one file you can't require. You could also try commenting out methods in the helper_methods until you find the one that triggers the problem.
If I am running a long R script from the command line (R --slave script.R), then how can I get it to give line numbers at errors?
I don't want to add debug commands to the script if at all possible; I just want R to behave like most other scripting languages.
This won't give you the line number, but it will tell you where the failure happens in the call stack which is very helpful:
traceback()
[Edit:] When running a script from the command line you will have to skip one or two calls, see traceback() for interactive and non-interactive R sessions
I'm not aware of another way to do this without the usual debugging suspects:
debug()
browser()
options(error=recover) [followed by options(error = NULL) to revert it]
You might want to look at this related post.
[Edit:] Sorry...just saw that you're running this from the command line. In that case I would suggest working with the options(error) functionality. Here's a simple example:
options(error = quote({dump.frames(to.file=TRUE); q()}))
You can create as elaborate a script as you want on an error condition, so you should just decide what information you need for debugging.
Otherwise, if there are specific areas you're concerned about (e.g. connecting to a database), then wrap them in a tryCatch() function.
Doing options(error=traceback) provides a little more information about the content of the lines leading up to the error. It causes a traceback to appear if there is an error, and for some errors it has the line number, prefixed by #. But it's hit or miss, many errors won't get line numbers.
Support for this will be forthcoming in R 2.10 and later. Duncan Murdoch just posted to r-devel on Sep 10 2009 about findLineNum and setBreapoint:
I've just added a couple of functions to R-devel to help with
debugging. findLineNum() finds which line of which function
corresponds to a particular line of source code; setBreakpoint() takes
the output of findLineNum, and calls trace() to set a breakpoint
there.
These rely on having source reference debug information in the code.
This is the default for code read by source(), but not for packages.
To get the source references in package code, set the environment
variable R_KEEP_PKG_SOURCE=yes, or within R, set
options(keep.source.pkgs=TRUE), then install the package from source
code. Read ?findLineNum for details on how to tell it to search
within packages, rather than limiting the search to the global
environment.
For example,
x <- " f <- function(a, b) {
if (a > b) {
a
} else {
b
}
}"
eval(parse(text=x)) # Normally you'd use source() to read a file...
findLineNum("<text>#3") # <text> is a dummy filename used by
parse(text=)
This will print
f step 2,3,2 in <environment: R_GlobalEnv>
and you can use
setBreakpoint("<text>#3")
to set a breakpoint there.
There are still some limitations (and probably bugs) in the code; I'll
be fixing thos
You do it by setting
options(show.error.locations = TRUE)
I just wonder why this setting is not a default in R? It should be, as it is in every other language.
Specifying the global R option for handling non-catastrophic errors worked for me, along with a customized workflow for retaining info about the error and examining this info after the failure. I am currently running R version 3.4.1.
Below, I've included a description of the workflow that worked for me, as well as some code I used to set the global error handling option in R.
As I have it configured, the error handling also creates an RData file containing all objects in working memory at the time of the error. This dump can be read back into R using load() and then the various environments as they existed at the time of the error can be inspected interactively using debugger(errorDump).
I will note that I was able to get line numbers in the traceback() output from any custom functions within the stack, but only if I used the keep.source=TRUE option when calling source() for any custom functions used in my script. Without this option, setting the global error handling option as below sent the full output of the traceback() to an error log named error.log, but line numbers were not available.
Here's the general steps I took in my workflow and how I was able to access the memory dump and error log after a non-interactive R failure.
I put the following at the top of the main script I was calling from the command line. This sets the global error handling option for the R session. My main script was called myMainScript.R. The various lines in the code have comments after them describing what they do. Basically, with this option, when R encounters an error that triggers stop(), it will create an RData (*.rda) dump file of working memory across all active environments in the directory ~/myUsername/directoryForDump and will also write an error log named error.log with some useful information to the same directory. You can modify this snippet to add other handling on error (e.g., add a timestamp to the dump file and error log filenames, etc.).
options(error = quote({
setwd('~/myUsername/directoryForDump'); # Set working directory where you want the dump to go, since dump.frames() doesn't seem to accept absolute file paths.
dump.frames("errorDump", to.file=TRUE, include.GlobalEnv=TRUE); # First dump to file; this dump is not accessible by the R session.
sink(file="error.log"); # Specify sink file to redirect all output.
dump.frames(); # Dump again to be able to retrieve error message and write to error log; this dump is accessible by the R session since not dumped to file.
cat(attr(last.dump,"error.message")); # Print error message to file, along with simplified stack trace.
cat('\nTraceback:');
cat('\n');
traceback(2); # Print full traceback of function calls with all parameters. The 2 passed to traceback omits the outermost two function calls.
sink();
q()}))
Make sure that from the main script and any subsequent function calls, anytime a function is sourced, the option keep.source=TRUE is used. That is, to source a function, you would use source('~/path/to/myFunction.R', keep.source=TRUE). This is required for the traceback() output to contain line numbers. It looks like you may also be able to set this option globally using options( keep.source=TRUE ), but I have not tested this to see if it works. If you don't need line numbers, you can omit this option.
From the terminal (outside R), call the main script in batch mode using Rscript myMainScript.R. This starts a new non-interactive R session and runs the script myMainScript.R. The code snippet given in step 1 that has been placed at the top of myMainScript.R sets the error handling option for the non-interactive R session.
Encounter an error somewhere within the execution of myMainScript.R. This may be in the main script itself, or nested several functions deep. When the error is encountered, handling will be performed as specified in step 1, and the R session will terminate.
An RData dump file named errorDump.rda and and error log named error.log are created in the directory specified by '~/myUsername/directoryForDump' in the global error handling option setting.
At your leisure, inspect error.log to review information about the error, including the error message itself and the full stack trace leading to the error. Here's an example of the log that's generated on error; note the numbers after the # character are the line numbers of the error at various points in the call stack:
Error in callNonExistFunc() : could not find function "callNonExistFunc"
Calls: test_multi_commodity_flow_cmd -> getExtendedConfigDF -> extendConfigDF
Traceback:
3: extendConfigDF(info_df, data_dir = user_dir, dlevel = dlevel) at test_multi_commodity_flow.R#304
2: getExtendedConfigDF(config_file_path, out_dir, dlevel) at test_multi_commodity_flow.R#352
1: test_multi_commodity_flow_cmd(config_file_path = config_file_path,
spot_file_path = spot_file_path, forward_file_path = forward_file_path,
data_dir = "../", user_dir = "Output", sim_type = "spot",
sim_scheme = "shape", sim_gran = "hourly", sim_adjust = "raw",
nsim = 5, start_date = "2017-07-01", end_date = "2017-12-31",
compute_averages = opt$compute_averages, compute_shapes = opt$compute_shapes,
overwrite = opt$overwrite, nmonths = opt$nmonths, forward_regime = opt$fregime,
ltfv_ratio = opt$ltfv_ratio, method = opt$method, dlevel = 0)
At your leisure, you may load errorDump.rda into an interactive R session using load('~/path/to/errorDump.rda'). Once loaded, call debugger(errorDump) to browse all R objects in memory in any of the active environments. See the R help on debugger() for more info.
This workflow is enormously helpful when running R in some type of production environment where you have non-interactive R sessions being initiated at the command line and you want information retained about unexpected errors. The ability to dump memory to a file you can use to inspect working memory at the time of the error, along with having the line numbers of the error in the call stack, facilitate speedy post-mortem debugging of what caused the error.
First, options(show.error.locations = TRUE) and then traceback(). The error line number will be displayed after #