I am writing a compiler in Ocaml with Emacs. I am told that with -annot a file .annot could be generated while compiling, which could help Emacs to show the type of my code. But it is odd that no .annot is generated after running this makefile. Could anyone tell me what is wrong with that?
Also, once i have got .annot, do I need to set up anything (for instance .emacs?) so that my Emacs read it and show the type of my code?
Thank you very much!
Edit1: after make clean and make, I have got the .annot... But I still do not know how to make use of this .annot in Emacs.
Edit2: actually it is necessary to follow this link, copy the files in a local folder, then update .emacs. Then when a .ml is edited in Emacs, C-c C-t returns its type from .annot.
Regarding your emacs inquiry --I don't use emacs--, this is from the man-pages for ocamlc,
-annot Dump detailed information about the compilation (types, bindings, tail-calls, etc). The information for file src.ml is put into file src.annot. In case of a type error, dump all the information inferred by the type-checker before the error. The src.annot file can be used with the emacs commands given in emacs/caml-types.el to display types and other annotations interactively.
There are also other tools from the thread I mentioned previously.
As for the Makefile not creating the .annot files, I made a mock directory and successfully had .annot files created. I also don't see anything wrong with your Makefile. You may want to clean the directory and try again, or switch to another way to build your tool like ocamlbuild --which would require minimal setup, although, I haven't used it with menhir.
I will also note that -annot is new since OCaml 3.11.0, and prior the flag was -dtypes.
Related
I'm new to using coq/coqIDE and I'm not computer savvy either so I don't know whats wrong or what to call the issue. I was trying to go through the Software Foundations book, but coqIDE isn't working right. I'm using the latest windows 10, and coqIDE 8.10.2
The first issue is when I go to the tab compile -> compile buffer in Basics.v, coqIDE doesn't create a .vo file or a .glob. None of the other buttons worked either. Running coqIDE as admin didn't make it work either, but I figured out I can get around this by manually dragging Basics.v into the coqc application file.
I had no issues with coq working during the first lesson, but in the next lesson we're meant to import the definitions from Basics.v into Induction.v, when I run what they say
From LF Require Export Basics.
I get the error The file C:\Users\...\Coq Files\Tutorial\lf\Basics.vo contains library Basics and not library LF.Basics even though the _CoqProject file contains "-Q . LF" as it should.
I can get around this error too by just writing "Require Export Basics."
which properly loads, up until I actually try calling a definition from Basics
Running
Require Export Basics.
Example example: evenb 2 = true.
works until I get to evenb, and then gives the error
The reference evenb was not found in the current environment. even though it's in Basics.v
If I get even more anal and try
Add LoadPath "C:\Users\...\Coq Files\Tutorial\lf".
From LF Require Export Basics.
I get the error
Cannot find a physical path bound to logical path matching suffix <> and prefix LF.
And then finally if I try
Add LoadPath "C:\Users\...\Coq Files\Tutorial\lf".
Require Export Basics.
Example example: evenb 2 = true.
Loads properly.
So I'm wondering how should I fix the load path so that the project works without putting that junk in every file and how do I make the compile tab work.
There were some people talking about "hitting make in the top-level" but I have no idea what that means. I tried it anyway and ran the Makefile as a .bat even though I already downloaded it properly so there shouldn't be any need, but the Makefile didn't change anything anyway.
I don't think I'm forgetting anything, thanks in advance.
Instead of choosing Compile > Compile buffer, try Compile > Make instead (when browsing any one of the vernacular files in Logical Foundations) - I think that is what others meant by "hitting make in the top-level". But first, you may want to remove the workarounds you added in e.g. Induction.v, and save a trivial change in Basics.v such as adding/removing a newline somewhere in order to convince make to recompile it.
I have an .ml file and I want to be able to run it line-by-line as if I was typing it in the top-level ocaml interpreter
The problem is, if I simply type "ocaml file.ml" in the terminal, I don't get the output from the REPL, and I can't debug and compile it, since it contains the #use directive.
I've tried using several different extensions for Visual Code, but none of them worked for me.
Is there anything I can do to simply be able to run the file and get the output from the ocaml REPL?
Thanks.
I never used VS Code (if you are referring it as 'Visual Code'), but SLIME in emacs or its Vim version of it is probably what you want.
Based on that, I tried searching for an VS Code extension that does works like SLIME: SendToREPL.
(Disclaimer: the author claims it works for Python, Node, and reply (not sure what it is though), but I am quite confident that it will work for OCaml REPL/UTop.)
I have installed the persp-mode and workspaces packages from the elpa repository. persp-mode depends on workspaces.
I was unable to get persp-mode working until the workspace.elc file was deleted. I have made a backup of this file for troubleshooting.
What could have been the cause of error?
How can I debug this problem systematically?
Without you giving us the error message it's hard to know what caused this, but generally the easiest way to debug compilation issues is to restart Emacs (so you have a fresh image), go back to the source file and recompile it with M-x emacs-lisp-byte-compile-and-load. This will show you any errors or warnings that occur when the file is compiled. Look for the following:
undefined variables and functions, which often indicate
features that have not been required by the package
simple typing errors
unexpected end of input errors, which indicate unbalanced parens
general usage errors, such as
function calls with incorrect argument counts
macro expansion errors
These sorts of issues are usually pretty easy to fix. Remember, you can always redefine the package's functions and vars yourself if they are broken.
I have CEDET working for the most part on emacs 24.2 with the latest from bzr
repository.
When I am searching for symbols or definitions, I see that the cedet mini-buffer
shows parses through a lot of files, some that are not there as header-files, the files
do not have any reference to the symbols I am searching.
I will leave CEDET to its job, let it search for symbols as it sees fit.
Is there any debug mechanism or verbose mode that I can turn on to see
1) What are all the files it is searching.
2) If it has found the GTAGS file at the base of my project. I understand that CEDET only
consults the GTAGS file to know about symbols.
I ask because there are some symbols that CEDET is unable to find the definition
for, but I'm able to find it from the gtags command line.
Thanks to Alex and Eric for their Numerous posts through-out the net.
This is a multi-step process.
First, make sure you've setup Global in the ways you want, such as via ede's locate feature, and through Symref.
Next, while visiting a file in a project you care about, use:
M-x cedet-gnu-global-show-root RET
to see if it can find a Global index file in that project.
Next, to see if symref found it, you need to eval this:
M-: (semantic-symref-detect-symref-tool)
and it will give you a symbol representing the tool it has chosen to use. It will say 'grep if it failed to use Global.
If you were in the middle of configuring things, you might need to reset things for you buffer. An easy way is to kill the buffer, and find it again, or:
M-x (setq semantic-symref-tool 'detect) RET
to force a detection again.
It seems this forum is more alive than mailing list : http://sourceforge.net/mailarchive/forum.php?forum_name=cedet-semantic.
I would like repost my quest from a week ago from there:
First hi to all who contribute to this great package as CEDET :D .
Without much hussle I am able to get working most of the CEDET futures, but when it comes to senator / semantic things get more tought :\ .
Parsing local files are fine.
I don't use EDE not to get things more complicated.
I use the 1.0.6 git trunk version, for compability with ECB.
First is the rumble about the emacs core / cedet git-trunk hussle. How do I check that current installation is running the latter ? ( I have done some .emacs modificaitons see below) .
I generally cannot get the proper autocomplete working for external libs - in this case the OGRE3D project, which all are in the /usr/include/OGRE. I suppose I have added to 'search path' include properly, semantic-describe-c-env. sees them added properly.
2.a What are the basic commands to the semantic parser ? , that is I need to force it to parse the desired includes.
Once I saw semantic parsing the OGRE files in the 'idle time'. Still the autocomplete does not work ( OGRE:RAY is not recongized as a type).
senator-completition-menu-pop gives some non-matching 'c**p'
2.b I know there are customize-group options for semantic, tough their description say little to me.
From the other post:
"Yes, there is a setup cost. You can use semanticdb.sh to pre-parse your
code, but if you never open every file, you might end up with Emacs
having such a huge data structure it gets larger that your machine can
handle. If your project is small, this shouldn't be a problem."
Well this might be, if that would parse OGRE.
here's my .emacs:
.emacs at pastebin.com
Here's what I got on the mailing list, hope that it would help someone , thaks to Eric Ludlam :D :
======================
1. First is the rumble about the emacs core / cedet git-trunk hussle. How do I check that current installation is running the latter ? ( I have done some .emacs modificaitons see below) .
After emacs start, use:
M-x cedet-version RET
and look for the 1.1 version from CEDET/bzr.
I just tried this and noticed not everything has the right version
number. Interesting. I'll have to look into that.
Anyway, the next thing to try is:
M-x locate-library RET cedet RET
and make sure it points where you think it should.
2. I generally cannot get the proper autocomplete working for external libs - in this case the OGRE3D project, which all are in the /usr/include/OGRE. I suppose I have added to 'search path' include properly, semantic-describe-c-env. sees them added properly.
If you enable global-semantic-decoration-mode you can right-click on
header files, and it will give you some options, such as showing where
it things the header is, and showing if it has been parsed yet or not.
2.a What are the basic commands to the semantic parser ? , that is I need to force it to parse the desired includes.
You can use the include menu to force a header to be parsed, or visit
said include. If it can't find it, you can add OGRE to your path from
there too.
If you vist your header, you can use the senator menu to force a file to
reparse, or use:
C-u M-x bovinate RET
to do it.
Once I saw semantic parsing the OGRE files in the 'idle time'. Still the autocomplete does not work ( OGRE:RAY is not recongized as a type). senator-completition-menu-pop gives some non-matching 'c**p'
Autocomplete can fail for many reasons. The best way to find out why is:
M-x semantic-analyze-debug-assist RET
at a place you want to do completion. It will tell you about your
header files, symbols, and the like. It could be your preprocessor
symbols need some setup.
For large complex library headers, sometimes it is just a matter of
having the right pre-processor symbols setup in Semantic so that the
right bits of the headers get parsed for symbols. You'd have to visit a
header where a symbol you want to complete is, and see if it was parsed.
Using:
M-x boviante RET
will dump the symbol table.
2.b I know there are customize-group options for semantic, tough their description say little to me.
From the other post:
"Yes, there is a setup cost. You can use semanticdb.sh to pre-parse your code, but if you never open *every* file, you might end up with Emacs having such a huge data structure it gets larger that your machine can handle. If your project is small, this shouldn't be a problem." Well this might be, if that would parse OGRE.
I doubt parsing the includes is the problem here. I think there is just
something new in the ogre headers we'll have to deal with.
Eric
===================================