i'm using the popular pythonscript ( http://code.google.com/p/edim-mobile/source/browse/trunk/ios/IncrementalLocalization/localize.py ) to localize my storyboards in ios5.
I did only some changes in storyboard and got this error:
Please file a bug at http://bugreport.apple.com with this warning
message and any useful information you can provide.
com.apple.ibtool.errors
description The strings
file "MainStoryboard.strings" could not be applied.
recovery-suggestion Missing object referenced
from oid-keyed mapping. Object ID ztT-UO-myJ
underlying-errors
description
The strings file "MainStoryboard.strings" could not be applied.
recovery-suggestion
Missing object referenced from oid-keyed mapping. Object ID ztT-UO-myJ
Traceback (most recent call last): File "./localize.py", line 105, in
raise Exception("\n" + errorDescription) Exception:
* Error while creating the 'Project/en.lproj/MainStoryboard.storyboard' file*
* Error while creating the 'Project/es.lproj/MainStoryboard.storyboard' file*
* Error while creating the 'Project/fr.lproj/MainStoryboard.storyboard' file*
* Error while creating the 'Project/it.lproj/MainStoryboard.storyboard' file*
Showing first 200 notices only Command /bin/sh failed with exit code 1
I can't find a solution..
Maik
I think when you made the changes to the storyboard, you removed an Interface Builder object from the storyboard with the ID ztT-UO-myJ. Hence the error message shown.
Try to search for that ID in MainStoryboard.strings file and remove the whole line. After that try again to run the script.
If ibtool fails with
Interface Builder could not open the document NAME.storyboard because
it does not exist
Execute this in terminal:
killall -9 ibtoold
Found at:
http://oleb.net/blog/2013/02/automating-strings-extraction-from-storyboards-for-localization/
P.S. The link contains a better script. https://github.com/ole/Storyboard-Strings-Extraction
P.S. This answer has links to articles about may be even better scripts
Related
■Error Description.
Error detected while processing function <SNR>35_debounceTimeTimerCallback[1]..
<SNR>35_tapSourceCallback[4]..<SNR>35_tapSourceCallback[1]..<lambda>30[1]..<SNR
>55_set_signs[10]..<SNR>55_place_signs:
line 5:
E716: Key not present in Dictionary: linecount + 1
■Cause of error content output
I have set up an environment for Go development using the Vim editor on VirtusalBox.
■Contents of .vimrc
call plug#begin('~/.vim/plugged')
Plug 'prabirshrestha/vim-lsp'
Plug 'mattn/vim-lsp-settings'
call plug#end()
I am unsure of the solution, can you please let me know?
It could be a bug of vim-lsp.
This pull request was merged to master 3 days ago. Removing the following lines from ~/.vim/plugged/vim-lsp/autoload/lsp/internal/diagnostics/signs.vim worked for me.
" Some language servers report an unexpected EOF one line past the end
if l:line == getbufinfo(a:bufnr)[0].linecount + 1
let l:line = l:line - 1
endif
You can see a list of the files that have been sourced by Vim with :help :scriptnames:
:scr
The XX in all the <SNR>XXs in the stack trace refers to script number XX in the output of the command above.
For example, this is the output of :scr in $ vim --clean on my machine:
1: ~/Applications/MacVim.app/Contents/Resources/vim/runtime/defaults.vim
2: ~/Applications/MacVim.app/Contents/Resources/vim/runtime/filetype.vim
3: ~/Applications/MacVim.app/Contents/Resources/vim/runtime/ftplugin.vim
4: ~/Applications/MacVim.app/Contents/Resources/vim/runtime/indent.vim
5: ~/Applications/MacVim.app/Contents/Resources/vim/runtime/syntax/syntax.vim
6: ~/Applications/MacVim.app/Contents/Resources/vim/runtime/syntax/synload.vim
7: ~/Applications/MacVim.app/Contents/Resources/vim/runtime/syntax/syncolor.vim
If I get a stack trace mentioning <SNR>4, I know the problem is in the ~/Applications/MacVim.app/Contents/Resources/vim/runtime/indent.vim file that comes with Vim. In this fictitious case, I would probably debug it a little bit further and open an issue on Vim's issue tracker.
In your case, the problem is very likely to happen in one of your plugins. Once you have identified it, you should head off to its issue tracker.
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.
How do you pass options to stack haddock from stack.yaml? I cannot find any clue to correct syntax neither in documentation nor in stack source code.
Documentation describes the following:
build:
haddock-arguments: ""
Naive haddock-arguments: "--odir=./docs" fails with type error:
…failed to parse field 'haddock-arguments': expected HaddockOptsMonoid, encountered String
I figured out that it expects it to be like:
build:
haddock-arguments:
odir: "./docs"
However it fails with error Unrecognized field in HaddockOptsMonoid: odir.
What is correct syntax of passing arguments from haddock manual to stack via stack.yaml? In my specific case, I want specify custom output directory.
After looking at the source I figured out that the syntax is
build:
haddock-arguments:
haddock-args:
- "--odir=./docs"
In a sample project this has the following result (notice the location of the docs directory deep down in .stack-work):
$ ls .stack-work/install/x86_64-linux/lts-6.3/7.10.3/doc/docs/ | cat
doc-index.html
frames.html
haddock-util.js
hslogo-16.png
index-frames.html
index.html
minus.gif
ocean.css
plus.gif
synopsis.png
The links in index.html are broken, so I'm slightly pessimistic that you can achieve what you want by passing arguments to haddock in this way.
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.
I have a custom error handler set up using set_error_handler. When I tried to include a file that doesn't exist, PHP calls error_handler one more time than it should:
<?php
error_reporting(E_ALL | E_STRICT);
set_error_handler(function($errno, $errstr, $errfile, $errline, $errcontext){
if(error_reporting() !== 0){
echo "<br>";
echo "<br>In Custom Error Handler...";
echo "<br>Err String: ", $errstr;
echo "<br>Passing to Default Handler...";
}
return false; // allow default
});
include("/missing_file.php"); // line 11
?>
Output:
In Custom Error Handler... // this is the extra error handler call
Err String: include(/missing_file.php)
[function.include]: failed to open stream: No such file or directory
Passing to Default Handler...
// the default handler does nothing, even though error_reporting is not zero
// Next Phase:
In Custom Error Handler...
Err String: include() [function.include]: Failed
opening '/missing_file.php' for inclusion
(include_path='.:/usr/lib/php:/usr/local/lib/php')
Passing to Default
Handler...
Warning: include() [function.include]: Failed opening
'/missing_file.php' for inclusion
in
/home/yccom/public_html/apr/test.php on line 11
The same behavior is observed with require.
For example, changing line 11 to require will give this output:
In Custom Error Handler... // this is the extra error handler call
Err String: require(/missing_file.php) [function.require]: failed to
open stream: No such file or directory
Passing to Default Handler...
// the default handler does nothing, even though error_reporting is
not zero
// Next Phase:
Fatal error: require() [function.require]: Failed opening required '/missing_file.php' in /home/yccom/public_html/apr/test.php on
line 11
What may be causing the error handler's additional call?
It's quite simple, really. PHP's lifecycle consists of 4 distinct phases:
Parsing
Compilation
Scanning
Execution
for your code to be parsed, all files that are included/required need to be fetched in the first phase, to translate the code into meaningful expressions. Your file doesn't exist, so a warning is issued.
Next, the compilation phase encounters the same include statement, and tries to convert the expressions into opcodes. The file doesn't exist, so a warning is issued.
Scanning translates code into tokens, which again cannot be done for the missing include file.
Execution time... The file cannot be executed because it is missing.
Why would PHP work like this? Isn't it stupid to blunder along, eventhough a file is missing?
In a way, yes, but include is used to include files that are non-critical to the script, if you really need that file's contents, you use require (but preferably require_once). The latter emits, as you stated, a fatal error, and stops everything dead in its tracks. That's what should happen if you're depending on another file for your code to function.
The require construct issues an E_COMPILER_ERROR, which effectively halts the compiler (not unlike __halt_compiler) at a given offset(the line where the failing require statement resides).
Check these slides for more details on each of the 4 main phases.
The reason why your code emits four warnings, is simply because PHP tries to include the file four times. Try running the script from the command line, but use strace:
$ strace -o output.txt php yourScript.php
open the output file, and see the internals of the Zend engine. Pay special attention to lines that look like:
lstat("/your/path/./file.php", 0x50113add8355) = -1//0x5... ~= 0xsomeaddress
You'll see where PHP goes looking for the file: it's all its include_path directories, the cwd, /usr/share/php, probably a pear or lib directory, and the include path you explicitly set.
I've gotten the idea to do this from this site, and based on the output I got, this seems to me to be the most plausible explanation as to why you see multiple errors.