I'm using odoc, along with dune to generate documentation for a library. This is made by doing: dune build #doc
However, this generates signatures like:
val print : Stdlib.Format.formatter -> t -> unit
While what i would like is:
val print : Format.formatter -> t -> unit
OCamldoc used to provide the -hide option which could do exactly this. Does odoc have something similar? If yes, how to use it from dune?
Optionnaly, it would be perfect to have a link to the Format module of the Stdlib but this is maybe asking too much
No, odoc did not have something similar at the time i asked the question.
However it seems that now it is (or soon wille be) the case, thanks to this PR, which allows you to specify which modules to open by default by doing:
odoc compile --open=Stdlib
Related
https://github.com/nlsandler/nqcc
At the above link, there is the compiler created by the author of this blog: https://norasandler.com/2017/11/29/Write-a-Compiler.html
I read through the first post and was faced with the problem that I almost always face when looking at a project on Github. Where to start?
I know the syntax for OCaml more or less, so I can read a single OCaml program and sort of understand what it does, but with a project at this level, I don't even know where the files of src/ are being called! You call the nqcc, and then what happens? How do we get to the ml files in src/? I'm having a hard time wrapping my head around this. Could someone guide me in how to navigate a huge project like this effectively?
In general, it involves understanding the build system, but your particular example is pretty easy to understand and is very transparent.
You need to know only two rules:
a binary foo corresponds to file foo.ml;
a module Foo corresponds to file Foo.ml1.
By applying these rules, we can figure out that nqcc.ml is the entry point. It calls the compile function which has the following definition (copied here for the ease of reference)
let compile prog_filename =
let source_lines = File.lines_of prog_filename in
let ast = Enum.reduce (fun line1 line2 -> line1^" "^line2) source_lines
|> Lex.lex
|> Parse.parse
in
Gen.generate prog_filename ast
So it refers to File, Enum, Lex, Parse, and Gen modules. The first two comes from the outside of the project (from the batteries library, which provides an extension to the OCaml standard library). While the last three correspond to lex.ml, parse.ml, and gen.ml files correspondingly.
1)) An optional but useful third rule:
a module Foo has the interface file named foo.mli
The interface file is sort of like a header file and make contain only types, and usually contains documentation.
The stuff in src/ gets compiled to nqcc.byte by setup.ml, which is run by the Makefile. setup.ml knows to do this by looking at the _oasis file, because all it does is call out to an ocaml build framework called OASIS. The nqcc shell script runs $(dirname $0)/nqcc.byte $1, which means "call the executable nqcc.byte in the same directory as this script, with the script's first argument".
How do you do this in general? Well, mostly experience. But starting with the Makefile or other build script is usually a good way to figure out what the main components are and how they hang together.
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.
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.
The answer to this is not "see the import address table".
I am looking to do some analysis on a few binaries that I am generating, specifically to get a better idea of what libraries and windows API functions I am using. I have used Dependency Walker to take a look at this, but some of the testing I have done indicates to me that there might be a lot of extra function calls put into the IAT, even if they arent called.
What I am looking for is a way to determine what functions are being called... not just what is being put in the IAT.
The best way would probably be to reverse it and look at all of the 'CALL's but I dont know a good way to do that either.
What is the best way to do this?
Launch WinDbg (Debugging tools of windows)
Open the executable you want to analyse.
run the following commands
!logexts.loge
!logexts.logo e v (enables verbose logging)
!logexts.logo e t (enables text logging)
g
Open the logviewer tool come along with debugging tools of windows to see the api's,
Default logs path is desktop\logexts
If you are using link.exe to link your binary, pass /MAP flag at the time of linking.
This will generate a MAP file(binary.map)...it will have functions which are used(not all functions).
I don't know if it's the "best way", but I would kinda agree to your suggestion that all the CALLs give a good overview.
With the "Ollydbg" debugger you can load your program, go the the exe module of your process and rightclick -> search for -> all intermodular calls.
This gives you a nice sortable, searchable list of all "CALL"s that appear in your module and lead to other modules.
I'd like to be able to get the AST for a given OCaml program (I'd like to walk the AST and generate an instrumented version of the code or do some kind of transformation, for example). Do any of the OCaml tools support this functionality?
Since OCaml 4.02.1 it is possible to use the PPX tools written bu Alain Frisch to precisely do this. Example:
% ocamlfind ppx_tools/dumpast -e "1 + 2"
1 + 2
==>
{pexp_desc =
Pexp_apply ({pexp_desc = Pexp_ident {txt = Lident "+"}},
[("", {pexp_desc = Pexp_constant (Const_int 1)});
("", {pexp_desc = Pexp_constant (Const_int 2)})])}
=========
It is possible to use this program to dump the AST of a normal code file as well, and various options control the degree of precision of the dump. In the example above, for instance, the location parameters of the AST are hidden.
camlp4 is a way to go. Here is a motivating example. The docs are sparse - true, but one can make his way reading through wiki, existing examples, tutorials, and maybe even camlp4 sources.
What you're looking for is [camlp4][1]. I haven't used camlp4 before, so I can't attest to it's virtues as software. I have heard of people using camlp5 [http://pauillac.inria.fr/~ddr/camlp5/] which, according to wikipedia, has better documentation than the current version of camlp4.
You can use compiler-libs to achieve this. See Parsetree, Asttypes, and Ast_helper.