I have a file that generates cc code using flex. When I use the version 2.5.4a-10 the codes works as expected.
If I use bit more recent version 2.5.37 or even newer like 2.6 the generated code seems not to allocate anything. It uses some pointers defined with nullptr and crashes.
I think the syntax has changed in between these versions. I find it also strange that Debian/Ubuntu have a package called flex-old saying:
flex is a tool for generating scanners: programs which recognize lexical
patterns in text. This is the old 2.5.4a version, which is no longer
being developed. You should normally choose flex, unless you have
legacy lexer files that do not work with a modern flex.
This product includes software developed by the University of California,
Berkeley and its contributors. The upstream source code can be found at
http://flex.sourceforge.net/
(Editor's note: Flex has moved to Github but v2.5.4a is not there.)
That version seems to be a big deal for others I suspect. Getting to my question:
Is there any manual or guide of what I have to do in order to port that code to generate some c++ code that works in more recent versions of flex?
EDIT: Here is my simple example taken from something larger:
int num_lines = 0, num_chars = 0;
%%
\n ++num_lines; ++num_chars;
. ++num_chars;
%%
int main()
{
yy_init=1;
yylex();
printf( "# of lines = %d, # of chars = %d\n",
num_lines, num_chars );
return 0;
}
flex it with flex file.l and build it with gcc lex.yy.c -lfl. Now, if you used version 2.5.4 it will work. With later versions it translates and compiles just fine, but when you run the program you will get segmentation fault.
I found the problem myself. The variable yy_init can be explicitly set in that old version. In newer versions it is not allowed. I'm not sure if that is intended, maybe someone can explain why this behavior is observed. I find it a bit strange.
If someone has a similar problem, you might want to take a look at the yy_init variable. Other than that I had no issues.
Related
I have question about replacing <THC/THC.h> method.
Recently, I'm working on installing different loss functions compiled with cpp and cuda.
However, what I faced was a fatal error of
'THC/THC.h': No such file or directory
I found out that TH(C) methods were currently deprecated in recent version of pytorch, and was replaced by ATen API (https://discuss.pytorch.org/t/question-about-thc-thc-h/147145/8).
For sure, downgrading my pytorch version will solve the problem. However, due to my GPU compatibility issue, I have no choice but to modify the script by myself. Therefore, my question can be summarized into follows.
First, how can I replace codes that have dependency of TH(C) method using ATen API?. Below are codes that I have to modify, replacing those three lines looked enough for my case.
#include <THC/THC.h>
extern THCState *state;
cudaStream_t stream = THCState_getCurrentStream(state);
Second, will single modification on cpp file be enough to clear the issue that I'm facing right now? (This is just a minor question, answer on first question will suffice me).
For reference, I attach the github link of the file I'm trying to build (https://github.com/sshaoshuai/Pointnet2.PyTorch).
After struggling for a while, I found the answer for my own.
In case of THCState_getCurrentStream, it could directly be replaced by at::cuda::getCurrentCUDAStream(). Therefore, modified code block was formulated as below.
//Comment Out
//#include <THE/THC.h>
//extern THCState *state;
//cudaStream_t stream = THCState_getCurrentStream(state);
//Replace with
#include <ATen/cuda/CUDAContext.h>
#include <ATen/cuda/CUDAEvent.h>
cudaStream_t stream = at::cuda::getCurrentCUDAStream();
After replacing the whole source code, I was able to successfully build the module.
Hope this helps.
Trying to run this USB Serial example (bottom) to learn MBED, but I get the following compilation error:
class "USBSerial" has no member "printf"
Is it possible it isn't implemented for the STM32F411? Or is this a problem with MBED itself?
Seems like this should be basic functionality. Not finding much useful info on google when searching for this error. Has anyone else seen this error before?
potentially useful details:
IDE: vscode/platformIO
platformio.ini:
[env:nucleo f411re]
platform = ststm32
framework = mbed
board = nucleo_f411re
monitor_speed = 115200
MBED version: 6.2 (as I recall from memory, though I doubt it matters since I checked the docs for a few versions and the API and example appears unchanged)
The method printf() (which is a C, not C++ concept anyway) does not exist, simple as that. Use sprintf() if that's what you're familar with, then USBSerial.write(), perhaps.
I use MinGW64 to compile c++ programs. But since I upgraded to Windows 10, I found my c program output Chinese will be garbled code.
I follow the online method, adding a code in the program header: SetConsoleOutputCP(65001);, then it fixes. but I think it's so troublesome to do this for each c++ program. What should I do?
I think this is my system's problem, the same code in Windows 7 is not a problem, I just want to find a more convenient solution instead of adding the same code to every file
There's the code:
#include <iostream>
#include <windows.h>
using namespace std;
int main()
{
SetConsoleOutputCP(65001);
cout << "文本" ; //Output will be garbled code if there's no line above
return 0;
}
The console in most operating systems only expects ASCII character input. In order to show some other char set you have to specify that in your code. The SetConsoleOutputCP command sets the "code page" windows should read from. By the way not all versions of windows have the same code for this command.
Please refer to the documentation found here.
The documentation suggests using EnumSystemCodePages to make sure the code for that language exists on that system.
P.S.
Your English is very good :)
EDIT
I tested your code on my computer with Visual Studio 2019 and got the following
Warning C4566 character represented by universal-character-name '\u6587' cannot be represented in the current code page (1255)
even with the SetConsoleOutputCP command you added. I assume you need to have chines installed for this to work. The problem is that I don't have the relevant code page for the windows console to look in for the char set. see this answer and this answer.
So i wanted to ask how to get "proper" Code Completion working for CodeBlocks 13.12 for c++, im running mint rosa at the moment.
By this i mean
string buf;
buf. <--This doesnt work - no suggestions
I would like the "." to show me relevant function/attribute names. It autocompletes variables and shows relevant type information, but nothing of the type mentioned above that originates from a library.
For example I see that this works for some cases
MyClass obj;
obj. <--This works
Using the ICU library with C++ I'm doing:
char const *lang = Locale::getDefault().getLanguage();
If I write a small test program and run it on my Mac system, I get en for lang. However, inside a larger group project I'm working on, I get root. Anybody have any idea why? I did find this:
http://userguide.icu-project.org/locale/resources
so my guess is that, when running under the larger system, some ICU resources aren't being found, but I don't know what resources, why they're not being found, or how to fix it.
Additional Information
/usr/bin/locale returns:
LANG="en_US.ISO8859-1"
LC_COLLATE="C"
LC_CTYPE="C"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL="C"
If I write a small C program:
char const *lang = setlocale( LC_ALL, "" ):
I get en_US.ISO8859-1.
OS: Mac OS X 10.6.4 (Snow Leopard)
ICU version: 4.3.4 (latest available via MacPorts).
A little help? Thanks.
root is surely an odd default locale - you don't see many native root-speakers these days.
But seriously, is it safe to assume on the larger system that someone hasn't called one of the variants of setDefault("root")?
What does something like /usr/bin/locale return on this system (if you can run that)?
ICU 4.4 now has a test program called 'icuinfo', does it also return root as the default locale?
What OS/platform is this on, and which version of ICU?