I am using bison to generate a parser, however, when compiling the parser with the MSVC, I get an error which suggests that there is an error containing too many characters at the line after the last line in my bison file.
I have written a parser for a DSL language which used bison 2.7 for windows, I recently tried to use Conan to manage my dependencies which allowed me to get a newer version of win_bison (3.3.2). I examined the generated C++ source file and I found that the end of the file contains the following snippet of code.
#line 80 "Grammar.y" // lalr1.cc:1243
'_m4eof'
_m4eof
The last 2 lines prevent compilation and generates the error messages, these lines would not appear with win_bison 2.7.
Related
I want to write a native custom visualizer for visual studio debugger. I started from scratch and I am following this example
https://github.com/microsoft/ConcordExtensibilitySamples/tree/main/CppCustomVisualizer/dll
But I am stuck generating the equivalent for "CppCustomVisualizer.Contract.h".
It is required to compile CppCustomVisualizer.dll. I read that vsdconfigtool generates this file, however when I run "vsdconfigtool mymodule.vsdconfigxml mymodule.vsdconfig" it says an input dll is required
"ERROR: No input dlls were specified on the command line. At least one .dll file is required to output a .vsdconfig file."
What is this input DLL?
It turns out there are two syntax, one for generating the header file and another for generating the vsdconfig file, I was mistakenly trying to generate both header and vsdconfig file in the same step. This is the syntax:
synax: VsdConfigTool <input_config> <input_dll> <ouput_config>
-or-
VsdConfigTool <input_config> <output_header>
mymodule.contract.h
If I run vsdconfigtool mymodule.vsdconfigxml mymodule.contract.h it generates the header file mymodule.contract.h.
Then, to generate the mymodule.vsdconfig, after having compiled mymodule.dll, vsdconfigtool mymodule.vsdconfigxml mymodule.dll mymodule.vsdconfig.
I'm developing a prototype using ARM's mbed OS. I'm newish to C++ so having syntastic working would be ideal, but it gets hung up on the import of "mbed.h".
The structure of the project is:
/
myfile.cpp
mbed-os/
mbed.h
Syntastic is saying fatal error: 'mbed.h' file not found.
How can I get Syntastic / GCC (or whatever it's using) to find the header files?
UPDATE:
Looks like including a .syntastic_cpp_config file with the following in is helping (but involved an absurdly painful process of add a line, run Syntastic, find the next missing header file):
-Imbed-os
-Imbed-os/cmsis
-Imbed-os/cmsis/TARGET_CORTEX_M
-Imbed-os/cmsis/TARGET_CORTEX_M/TOOLCHAIN_GCC
-Imbed-os/drivers
-Imbed-os/events
-Imbed-os/features
-Imbed-os/hal
-Imbed-os/platform
-Imbed-os/rtos
-Imbed-os/targets
-Imbed-os/targets/TARGET_NORDIC/TARGET_NRF5
-Imbed-os/targets/TARGET_NORDIC/TARGET_NRF5/TARGET_MCU_NRF52832
-Imbed-os/targets/TARGET_NORDIC/TARGET_NRF5/TARGET_MCU_NRF52832/TARGET_NRF52_DK
-Imbed-os/targets/TARGET_NORDIC/TARGET_NRF5/TARGET_MCU_NRF52832/device
-Imbed-os/targets/TARGET_NORDIC/TARGET_NRF5/TARGET_SDK11/device
-Imbed-os/tools
This isn't a complete list at all, but I'd almost rather just hit compiler errors at this state and work with those rather than continue hunting for header files.
You can get an exhaustive list of flags by generating the Makefile of your project with :
mbed export -i make_gcc_arm -m K64F --profile mbed-os/tools/profiles/debug.json
cf: https://os.mbed.com/docs/v5.6/tools/debugging.html
I was using ast module of python3.4 to get the imports and function calls within a file.
It works correctly if I run the code on a file which has python3.4 syntax but throws an exception if I try to parse a file of older python2.7 version (for print statements, except statements which have a "," etc).
Is there a way to force ast to use python2.7 compiler while dealing with old files and use python3.4 compiler when dealing with python3.4 file?
Is there any other way to resolve this issue??
Turns out it is not possible to use different versions of AST parsers in python to the best of my knowledge. (It is still possible to parse them separately by carrying out multiple iterations each time using a different version AST)
I'm trying to get my .emacs set up so I can do builds of VS2012 projects from inside Emacs.
I followed the instructions on Emacswiki for doing this. It worked in the past for me with VS2005.
The problem is that this new version of VS appends a CPU designation on the front of every error/warning line, and emacs' C++ compiler parsing is getting confused and thinking that's part of the file name. For example, the error:
5>c:\dev\proj\my_class.h(35): warning C4100: 'command' : unreferenced formal parameter (my_class.cpp)
When visited with "next error", instead of bringing up the file and line, gives me the prompt:
Find this error in (default 5>my_class.h): ~/dev/proj/
Is there a tweak I can make in my .emacs (or perhaps the C and C++ modes) to fix this? Alternatively, is there a newer version of Emacs (or the mode .el files) that deals with VS2012 better? I'm currently using GNU Emacs 24.2.1
I think I've tracked this down.
The issue was not that GNU Emacs didn't try to support VS2012 compiler messages, the issue was that it had a couple of bugs in its support (in 24.2.1).
A bit of background: All the regexps Emacs uses to recognize errors and warnings are in a variable with the enchantingly redundant name of compilation-error-regexp-alist-alist. This is declared inside of the compile.el elisp file.
The main issue is that the first match found in the list is used, not the largest. There's a regexp on that list for edg-1 (Edison Design Group's front end for LLVM) that happens to match VS2012 errors and warnings. It was earlier in the list than the msft, so it was being used instead. Presto: bad directory match.
The issue was discussed in this thread on the emacs dev list, and fixed with a patch on 10/14/2012.
There are two fairly easy solutions.
Upgrade to Emacs 24.3 or later. This should have the patch.
(for the handy) Edit your lisp/progmodes/compile.el file. Find the "msft" entry in compilation-error-regexp-alist-alist, and move it somewhere in front of the offending "edg-1" entry. While you are at it, you may want to add a ? at the end of the first regexp line before the backslash (see the diff link). Then byte-compile the file and restart emacs.
I have a compiled fortran 90 code "NewSourceID.exe"in folder E:\TROUBLESHOOT. This uses input file MAIN.IN in the same folder. I use a batch script run_sa.BAT in the same folder E:\TROUBLESHOOT to run this executable. This batch script is generated at run time by another VB code (this is a requirement and cannot be done away with) and the batch script reads as following.
"E:\TROUBLESHOOT\NewSourceID.exe" "E:\TROUBLESHOOT\MAIN.IN".
There are two scenarios
1. When I go to the folder E:\TROUBLESHOOT and double click the batch script run_sa.BAT the NewSourceID.exe runs correctly without any problem. It runs on the command prompt window showing the path C:\WINDOWS\system32\command.exe.
When I run the same from the VB script by generating the batch script at runtime I get the following error.
"
C:\Documents and Settings\epsuser\My Documents>"E:\TROUBLESHOOT\NewSourceID.exe"
"E:\TROUBLESHOOT\MAIN.IN"
forrtl: severe (29): file not found, unit 31, file C:\Documents and Settings\eps
user\My Documents\MAIN.IN
The code tries to find the input file MAIN.IN on the path C:\Documents and Settings\epsuser\My Documents\MAIN.IN which is not the correct path to look for the file.
This happened when I replaced the NewSourceID.exe with a modified one. Earlier the code used to run correctly even from the VB with the following path. C:\WINDOWS\system32\command.exe -E:\TROUBLESHOOT\run_sa.BAT. How can this be done?
Are you sure, the Fortran program NewSourceID reads the command line argument you pass to it? Especially older Fortran programs (before Fortran 2003) had no standard way to parse command line arguments. I guess, the name MAIN.IN is hardwired in the code you use, and it always uses the MAIN.IN file from the current directory. You could work around this by issuing a change directory command before executing the program. I am not very familiar with Windows, but something like
cd E:\TROUBLESHOOT
E:\TROUBLESHOOT\NewSourceID.exe
in your batch script would probably work.
Alternatively, you could implement proper command line argument parsing in your Fortran code, using the command_argument_count() and get_command_argument() functions. You would need a Fortran 2003 compiler for that.