I don't know the effect of option dsource of ocamlc.the -h option tell me it's undocumented
I know the use of dparsetree and dtypedtree,it can show me the ast
I try to use the option dsource,to a file test.ml,It seems to return me the source code,without the null line and the comment,and at bottom tell me the waring of the source code.
Is it the effect of option dsource?Thanks!
-dsource pretty-prints the AST using the OCaml syntax after desugarring syntax extensions such as camlp4 and ppx.
It's mostly used to debug ppxs. The content is exactly the same as -dparsetree (except in source form, instead of AST).
I just spent a few minutes grepping the OCaml compiler sources, and here is what I found.
The -dsource command-line flag sets the dump_source field to true in the Clflags module.
This setting in turn causes the compiler to do something like this in driver/compile.ml when compiling an implementation (.ml) file.
if !Clflags.dump_source then
fprintf ppf "%a#." Pprintast.structure ast
In other words, it pretty-prints the code part of the AST in a form that looks like source code.
Things look similar for an interface (.mli) file, except that it prints out the signature rather than the code.
Since OCaml has a rather flexible front-end, I would guess this is helpful to see the final result of any syntactic transformations that have been applied to the code. (But I might be wrong, I'm not an OCaml compiler hacker.)
I suggest you start looking at the code in driver/compile.ml if you want to figure out more.
Related
I've been able to implement an ASTFrontendAction to create an ASTConsumer, which uses a RescursiveASTVisitor to traverse a translation unit decl, thereby visiting all the nodes of an AST for a given source file. I do this by implementing a ToolAction which is passed to ClangTool::run(ToolAction *action). This tool overrides the ToolAction::runInvocation member function to do some processing between each call to my ASTFrontendAction. So far so good, everything is working as expected, and my custom clang tool is helping me better explore a rather large, over 15 years old code base.
However, every time I want to run my tool, I need to do a full blown parse of the ASTs. As I mentioned, this is a rather large code base, so it takes a while to do a single run. I have gathered, by looking through the code, that it is possible to create and traverse an AST from a saved file, rather than perform the parse. Googling around confirmed that it's possible to save an AST, and by looking at the ClangTool and ASTUnit API, it seems it's pretty easy to do.
While it seems straightforward to save the AST, I have no idea how to make use of a saved AST when running my custom clang tool. Looking at the code path for running a tool, I see there is a point where the AST is created either by parsing a source file or by reading it from a file. What I would like to do is have all my ASTs available in a file(s), so that each run of my tool will create the ASTs from a file, and not need to perform a full parse (which, I assume would be much faster).
Could someone please help? Thanks in advance!
This worked for me:
clang::CompilerInstance CI;
CI.createDiagnostics();
std::shared_ptr<clang::TargetOptions> TO = std::make_shared<clang::TargetOptions>();
TO->Triple = "x86_64-pc-win32"; // see clang -v
CI.setTarget(clang::TargetInfo::CreateTargetInfo(CI.getDiagnostics(), TO));
std::unique_ptr<ASTUnit> ast = ASTUnit::LoadFromASTFile("TheAstFile.ast",
CI.getPCHContainerReader(),
ASTUnit::LoadEverything,
&CI.getDiagnostics(),
CI.getFileSystemOpts());
MyAstConsumer consumer(ast->getASTContext());
consumer.HandleTranslationUnit(ast->getASTContext());
I have a C++ project in which comments of source code are in Chinese language, now I want to convert them into English.
I tried to solve using google translator but got an Issue: Whole CPP files or header didn't get converted, also I have found the name of the struct, class etc gets changed. Sometimes code also gets modified.
Note: Each .cpp or .h file is less than 1000 lines of code.But there are multiple C++ projects each having around 10 files. Thus I have around 50 files for which I need to translate Chinese text to English.
Well, what did you expect? Google Translate doesn't know what a CPP file is and how to treat it. You'll have to write your own program that extracts comments from them (not that hard), runs just those through Google Translate, and then puts them back in.
Mind you, if there is commented out code, or the comments reference variable names, those will get translated too. Detecting and handling these cases is a lot harder already.
Extracting comments is a lexical issue, and mostly a quite simple one.
In a few hours, you could write (e.g. with flex) some simple command line program extracting them. And a good editor (such as GNU emacs) could even be configured to run that filter on selected code chunks.
(handling a few corner cases, such as raw string literals, might be slightly more difficult, but these don't happen often and you might handle them manually)
BTW, if you are assigned to work on that code, you'll need to understand it, and that takes much more time than copy&pasting or editing each comments manually.
At last, I am not sure of the quality of automatic translation of code comments. You might be disappointed. Also, the code names (of functions, of classes, of variables, etc...) matter a lot more.
Perhaps adding your comments in English could be wiser.
Don't forget to use some version control system. You really need one (e.g. git)
(I am not convinced that extracting comments for automatic translation would help your work)
First separate both comment and code part in different file using python script as below,
import sys
file=sys.argv[1]
f=open(file,"r")
lines=f.readlines()
f.close()
comment=open("comment.txt","w+")
code=open("code.txt","w+")
for l in lines:
if "//" in l:
comment.write(l)
code.write("\n")
else:
code.write(l)
comment.write("\n")
comment.close()
code.close()
Now translate comment.txt with google translator and then use
paste code.txt comment_en > source
where comment_en is translated comment in english.
I am on a migration project to move a C++ application from HP-UX to redhad 6.4 server. Now there is a parser application written using lex-yacc, which works fine in HP-UX. Now once we moved the lex specification file (l file) and yacc specification file (y file) to the RHEL 6.4 server, we compiled the code into new system without much change. But the generated parser is not working, everytime it is giving some syntax error with same input file which is correctly parsed in HP-UX. Now as per some reference material on lex and flex incompatibility, there are below points I see in the l file -
It has redefined input, unput and output methods.
The yylineno variable is initialized, and incremented in the redifined input method when '\n' character is found.
The data in lex is read from standard input cin, which looks to be in scanner mode.
How can I find out the possible incompatibilities and remedies for this issue? And is there any way other than using gdb to debug the parser?
Both flex and yacc/bison have useful trace features which can aid in debugging grammars.
For flex, simply regenerate the scanner with the -d option, which will cause a trace line to be written to stderr every time a pattern is matched (whether or not it generates a token). I'm not sure how line number tracking by the debugging option will work with your program's explicit yylineno manipulation, but I guess that is just cosmetic. (Personally, unless you have a good reason not to, I'd just let flex track line numbers.)
For bison, you need to both include tracing code in the parser, and enable tracing in the executable. You do the former with the -t command-line option, and the latter by assigning a non-zero value to the global variable yydebug. See the bison manual for more details and options.
These options may or may not work with the HPUX tools, but it would be worth trying because that will give you two sets of traces which you can compare.
You don't want to debug the generated code, you want to debug the parser (lex/yacc code).
I would first verify the lexer is returning the same stream of tokens on both platforms.
Then reduce the problem. You know the line of input that the syntax error occurs on. Create a stripped down parser that supports parsing the contents of that line, and if you can't figure out what is going on from that, post the reduced code.
So I've been trying to implement an #if parser into an infobox, but I seem to be out of luck. The previous code I used seems to be outdated, and I can't find the a way to code it in again, differentely. :/
Basically, in this infobox, if a field is not typed in(or if typed in is left empty) it should become 'invisible' or not even render.
This code worked fine in a previous version of MediaWiki(not sure which one though), but no longer: http://pastebin.com/uQ49mPbQ. I've been trying to use it as a tutorial, and even outright copy and pasted it, but it simply doesn't work. All of the fields would become invisible, regardless of what I would have done to them...
This is the new code that I am using, and would like to be #if'ed: http://pastebin.com/3j0AbN5v
Any help would be welcome.
You need to enable the ParserFunctions extension to be able to use the {{#if}} parser function. Do this in your LocalSettings.php:
require_once( "$IP/extensions/ParserFunctions/ParserFunctions.php" );
If you want to use the string functions (like {{#replace}}, {{#explode}}, etc), also add:
$wgPFEnableStringFunctions = true;
In recent versions of MediaWiki, ParserFunctions is included (but not enabled) so you don't need to download anything.
Basic troubleshooting: Whenever you see code like {{#zyx:...}} in a wiki page, it (probably) means, that someone tried to use a parser function that is not installed. Unless there is a parser function called “zyx” installed, the code {{#zyx:...}} has no special meaning to the wiki, and the text will be printed just like it is. The most common parser functions are collected in an extension called ParserFunctions, that is used on WikiMedia wikis. You will need the parser functions from ParserFunctions whenever copying templates from e.g. English Wikipedia.
To see what parser functions you have enabled, navigate to Special:Version on your wiki. Below the list of installed extensions is a list of tags (such as <gallery />) and parser functions available. As you can see, “if” is among the parser functions on your old wiki, but not on your new.
I want to be able to see what the AST of a certain module would be so I can write a proper filter against it.
As I right now don't really see how I can 'log' in a filter, for example I try to match and when the match fails I log, I use the Camlp4AstLifter function to translate the module into a tree, which is then printed out on the console, and like that I try to create my match patterns, like so:
camlp4o -filter Camlp4AstLifter -printer o name_of_file.ml
This falls a bit short right now when I would like to take an mli file and use a camlp4 filter to create a default implementation of this mli file.
I cannot use Camlp4AstLifter to see the tree, becuase this command doesn't seem to work with mli's (it shows me the mli again as output) and therefore I'm a bit blind while trying to match.
Anybody got an idea? Or maybe a hint on how to improve my filtering/matching approach (I don't get the feeling I'm doing it right yet, very tedious).
Kasper
Put module type S = <contents of mli file> into ml file and apply the lifter?
The ocaml compilers have some undocumented switches, that are nevertheless shown when doing ocamlc -h (probably thanks to the module Arg), ocamlopt has even more:
-dsource (undocumented)
-dparsetree (undocumented)
-dtypedtree (undocumented)
-drawlambda (undocumented)
-dlambda (undocumented)
-dclambda (undocumented)
...
I found out that -dsource gives a prettyprinting of the source. Your desired option should be there, too.