When using EDTS erlang emacs IDE, it doesn't seem to me that there is much integration with rebar, so I am wondering how to specify compile options so that I can add debug_info and {parse_transform, lager_transform}.
EDTS kinda works on .beams, and with this it should be able to compile with exactly the same options. Let me explain.
EDTS works with notion of project (it's accualy xref server, lets assume that those are more or less the same). When you open one source file, he adds it to the "project list", and than he adds all other modules he can find. What is important here, is fact that he is doing it based on .beam files. It have two major significance.
First, if you modules aren't compiled he will think that you make calls to undefined functions (with exception of files that you actually opened in your editor, of course).
Second is fact, that if he can find once compiled binary, he can read and reuse compile flags from it. Of course all new files created in emacs won't have .beam with those options, so they will be compiled with default ones.
So, if you have any issues with the way your files are compiled/modules you can reference just recompile them from command line
$ ./rebar clean compile
and reinitialize EDTS with M-x edts-project-node-refresh or M-x edts-project-node-init
Related
I am running CoqIDE to use read the textbook series "Software Foundations", I am currently reading the volume "Logical Foundations". I just started Chapter 2 (Induction), but when I try to run the line
From LF Require Import Basics.
I get an error statement
The file ...\LF\Basics.vo contains library
Basics and not library LF.Basics
I tried renaming the directory the file was located in, and recompiled the buffers, but neither of these actions helped. What Shoudl i do in order to solve this problem?
We've been improving the explanation in the soon-to-be-released new version of LF. Here is the relevant bit:
For the [Require Export] to work, Coq needs to be able to
find a compiled version of [Basics.v], called [Basics.vo], in a directory
associated with the prefix [LF]. This file is analogous to the [.class]
files compiled from [.java] source files and the [.o] files compiled from
[.c] files.
First create a file named [_CoqProject] containing the following line
(if you obtained the whole volume "Logical Foundations" as a single
archive, a [_CoqProject] should already exist and you can skip this step):
[-Q . LF]
This maps the current directory ("[.]", which contains [Basics.v],
[Induction.v], etc.) to the prefix (or "logical directory") "[LF]".
PG and CoqIDE read [_CoqProject] automatically, so they know to where to
look for the file [Basics.vo] corresponding to the library [LF.Basics].
Once [_CoqProject] is thus created, there are various ways to build
[Basics.vo]:
- In Proof General: The compilation can be made to happen automatically
when you submit the [Require] line above to PG, by setting the emacs
variable [coq-compile-before-require] to [t].
- In CoqIDE: Open [Basics.v]; then, in the "Compile" menu, click
on "Compile Buffer".
- From the command line: Generate a [Makefile] using the [coq_makefile]
utility, that comes installed with Coq (if you obtained the whole
volume as a single archive, a [Makefile] should already exist
and you can skip this step):
[coq_makefile -f _CoqProject *.v -o Makefile]
Note: You should rerun that command whenever you add or remove Coq files
to the directory.
Then you can compile [Basics.v] by running [make] with the corresponding
[.vo] file as a target:
[make Basics.vo]
All files in the directory can be compiled by giving no arguments:
[make]
Under the hood, [make] uses the Coq compiler, [coqc]. You can also
run [coqc] directly:
[coqc -Q . LF Basics.v]
But [make] also calculates dependencies between source files to compile
them in the right order, so [make] should generally be prefered over
explicit [coqc].
If you have trouble (e.g., if you get complaints about missing
identifiers later in the file), it may be because the "load path"
for Coq is not set up correctly. The [Print LoadPath.] command
may be helpful in sorting out such issues.
In particular, if you see a message like
[Compiled library Foo makes inconsistent assumptions over
library Bar]
check whether you have multiple installations of Coq on your machine.
It may be that commands (like [coqc]) that you execute in a terminal
window are getting a different version of Coq than commands executed by
Proof General or CoqIDE.
- Another common reason is that the library [Bar] was modified and
recompiled without also recompiling [Foo] which depends on it. Recompile
[Foo], or everything if too many files are affected. (Using the third
solution above: [make clean; make].)
One more tip for CoqIDE users: If you see messages like [Error:
Unable to locate library Basics], a likely reason is
inconsistencies between compiling things _within CoqIDE_ vs _using
[coqc] from the command line_. This typically happens when there
are two incompatible versions of [coqc] installed on your
system (one associated with CoqIDE, and one associated with [coqc]
from the terminal). The workaround for this situation is
compiling using CoqIDE only (i.e. choosing "make" from the menu),
and avoiding using [coqc] directly at all. *)
I'm trying to get to grips with the babel transpiler. It's docs start by telling you how to install it globally, and then, shortly thereafter tells you you should never do this, and never explains how to run it that way. Well, I believe I wish to run it that way (because the presence of the node_modules directory, or possibly the .babelrc file, cripples brackets, which is the editor I'm currently needing to use).
I can run babel from the global installation easily enough, but it doesn't do anything. The only way I've succeeded in getting it to do any actual translation has been using the local invocation with the .babelrc file, which of course kills my editor (and yes, I actually do have to use that, and I'm not creating a node-based project in any other way, just plain ES6).
Is there some way to use the command line to provide the information that the .babelrc file specifies (and thereby have something other than simply file copying)? Or some other way to get babel to do what I need without physical presence in my source tree?
I am using Eclipse Juno CDT for a class I am taking, but it is telling me it can't resolve types found in include files, and these aren't headers I wrote.
The program I wrote compiles and runs exactly as it should if I run it through g++ via the command line. The problem is that I can't debug in Eclipse because it doesn't recognize even basic types like string. Also, no code completion. It finds the include files just fine, I can open those and look at the contents, but it still won't resolve types.
I've seen lots of suggestions for people with similar problems, but those all turned out to be not finding the include files, which isn't my problem. Any suggestions?
Maybe the types are in a namespace and you're not qualifying them (and not using a using declaration).
You likely have included the proper directory for the headers themselves. On my system it is: /usr/include/c++/4.4.6/
However, you probably don't have the directory containing the definition of the macro _GLIBCXX_BEGIN_NAMESPACE. Without this macro definition eclipse does not know that the stl types are in the std namespace. On my system this macro definition is squirreled away beneath the main c++ dir. Try adding the following paths to your include list:
/usr/include/c++/4.4.6/x86_64-redhat-linux
/usr/include/c++/4.4.6/x86_64-redhat-linux/bits
If you're not on redhat look for something similar. You can go to /usr/include and run the following grep to look for the headers with the necessary macro definition:
grep -R -P "define\\s*_GLIBCXX_BEGIN_NAMESPACE\(" .
I use a wrapper around make to compile C++ code within a project.
For example, the project Foo is laid out as follows:
Foo/
Foo/src/...
Foo/lib_1/..
Foo/lib_2/...
etc
where lib_1, lib_2 are library dependencies of Foo. The src directory has a single
make file which I run on the command line.
Is there a way to teach emacs to always run that file when I do M-x compile? And understand how
to jump to an error in some other file buffer (or open a new buffer for a file) depending on
what the error is on running make (g++) ?
Edit: I guess what I am asking for is project support and support within the project to run a specific custom make file, where errors point to files within the project that emacs can navigate to.
See the variable compile-command. This is what M-x compile defaults to, so you can set it to run the makefile you want. E.g.
cd /your/root/dir ; make
Also see the command recompile if you don't want to always press enter. It's also worth it to bind it to some key.
I'd like to play around with integrating coffeescript into my dev process. But as I see it, I'll have to make a bat file that iterates a set of coffee files and spits out js files. Every time I write a bat file, useful as they may be, I ask myself: is there a better way?
Which makes me wonder: is there an app of some sort for Windows that will watch a directory or a file and spit out one/many js files when a coffee file is saved? I'm thinking of building one but don't want to reinvent the wheel. I looked around and found things that were similar but nothing that elevated it beyond "run this command line" on Windows.
Edit: already marked an answer, but looking at this 10 months later the answer is: grunt. Because it'll do a lot more than just auto-compile your coffeescript and you'll probably need to do more than just that to get your app going.
coffee --watch -o lib -c src
where src is a directory containing your coffee files, and lib is your JavaScript output directory.
See update at bottom of post.
I was hunting for the same thing the other day and came across this: https://github.com/danenania/CoffeePy
It's a simple python script that uses PyV8 to run coffee-script.js.
It doesn't do anything fancy, just watches a folder recursively, and compiles any .coffee files whenever they're changed. It doesn't even have a bare option. These things could be very easily added though!
Edit:
I forked the script and added --bare and --output options.
You can get it here: https://github.com/johtso/CoffeePy
Personally, I prefer using build tools like grunt.js / yeoman or brunch for that purpose.
grunt.js
&
grunt coffee
Mindscape Workbench has a built in compiler/editor for VS 2010. Haven't tried it yet, but it looks like it'd be even better than a watcher/compiler. Scott Hanselman has a post about it here:
http://www.hanselman.com/blog/CoffeeScriptSassAndLESSSupportForVisualStudioAndASPNETWithTheMindscapeWebWorkbench.aspx
I think there is a simplier way just using -w option of coffeescript compiler
coffee -c -w *.coffee
This will compile all coffee files under the folder you are (put more file pathes if needed) each time you change one.
Another possibility: WebStorm 6. They've added a built in file-watcher for a variety of next-gen languages like SASS and Coffescript.
If you want a different way of doing it, this might help:
http://jashkenas.github.com/coffee-script/#scripts
If you include the coffeescript compiler on your page, you can include files with a "text/coffeescript" type and they will get compiled client-side.
Word of warning: Obviously, client-side compilation is not for something serious, but its completely fine for a small project/quick development. It would then be trivial to compile them on the server and change the MIME-type and filename when something a bit quicker is necessary.
CoffeeScript-dotnet does what you want, but it is a command line tool.
Command line tool for compiling CoffeeScript. Includes a file system watcher to automatically recompile CoffeeScripts when they change. Roughly equivalent to the coffee-script node package for linux / mac.
Here is the best way to do it:
Say your work is in "my-project-path" folder.
Go to the parent folder of "my-project-path"
Start a terminal and type coffee -o my-project-path -cw my-project-path
This line will watch and compile anything name as "*.coffee" in "my-project-path" folder, even if it is in "my-project-path/scripts/core" or "my-project-path/test/core".The js file will locate in the save folder as the .coffee file.