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\(" .
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. *)
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
This is my first couple of hours of Erlang experimentation. So be gentle, please.
I checked out a project (https://github.com/wooga/eredis)
Installed rebar
Compiled the modules (beam files went into ebin)
Fired up erl -pa ./ebin
Typed eredi - and hit tab
At this point nothing was displayed, whereas all other modules were auto-completed. So I (reasonably) assumed that the module beam files hadn't been loaded - lead me to all sorts of fruitless investigations of paths, etc.
But the code had been loaded, it just wasn't being auto-completed.
1> {ok,C} = eredis:start_link().
{ok,<0.35.0>}
2> eredis:q(C,["SET","foo","bar"]).
{ok,<<"OK">>}
3> eredis:q(C,["GET","foo"]).
{ok,<<"bar">>}
Great, but I'd really like auto-complete to work. Is there a way to get it working? In Zsh for example, I have to execute rehash for new path items to show up - do I need to execute something similar here?
You need to make sure the module is loaded in the shell, adding it to the path with -pa just tells the VM where to look for modules when trying to load them.
There are several ways of loading a module
Call a function in the module that should be loaded (so after doing the eredis:start_link() call you would be able to tab-complete eredis)
Explicitly load the module with l(Module)
Programmatically: code:load_file(Module)
Load all erlang modules in path is very useful!
Due to the fact that we need to integrate the Zend Framework on our project root, and that generating that documentation will be useless and take long time, I would like to generate documentation for all files inside application folder only.
Does anyone know how I can generate documentation for a specific project folder, trough Netbeans 7.0 interface?
Update:
The best I've found so far was to:
Open the terminal window from netbeans, and type:
sudo phpdoc -d public_html/yoursite.dev/application/ -t public_html/yoursite.dev/docs/
Update 2
Let's suppose our Zend library is inside projectrootname/library/Zend we also can try, by going to: Tools > Options > Php > PhpDoc and place the following:
/usr/bin/phpdoc -i library/Zend/ -o HTML:frames:earthli
At least for me, that doesn't seem to work, because, when I try to generate the documentation, I get permission error issues displayed on the output window.
Thanks
The -d/--directory option [1] should be used to highlight the most high-level code directory that you want phpDocumentor to start reading from. If your Zend folder is at or above the level of your application directory, then just using --directory /path/to/application should help you document only your application code.
If your Zend folder is somewhere inside your application (e.g. in your app's ./lib folder), then you can use the -i/--ignore option [2] to tell phpDocumentor about any directories that it will see but should ignore, --ignore *zend*. Just be aware that formatting your ignore value can be tricky, so see the examples in the manual. Also, be aware that as phpDocumentor runs, you will see these ignored folders and files being listed in the output... phpDocumentor "ignores" them by not generating docs for those files. It does, however, still need to parse them, in case those objects are referenced in files that do get documented.
[1] -- http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_phpDocumentor.howto.pkg.html#using.command-line.directory
[2] -- http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_phpDocumentor.howto.pkg.html#using.command-line.ignore
How do I build Borland C++ project files (bpr) and package files (bpk) from the command line? Project groups (bpg) are apparently make files and can be compile with make. But bpks and bprs are xml based and the Export to Makefile won't compile with make.
If I put a project in a bpg, make can't seem to find any of the files specified in the bpg since they all appear to be relative references. I changed the references to absolutes and make reports:
Fatal: Unable to open makefile
You don't need to directly compile a bpr. Just create a bpk which just includes that single bpr, and you can use make to compile it.
"c:\program files\borland\cbuilder5\bin\make" -B -s -fabc.bpg
If you also have other borland compilers installed, do not call the make.exe from the other compiler.
EDIT: execute the make command in the directory where the bpg and bpr is located.
Using bpr2mak and make works for me just fine, so as Roger said, you need to give details on what errors you're getting. BPK files can also be processed with bpr2mak. I'm using this method to compile a large project with many components, without difficulties.
Perhaps you could give some more information on 'won't compile'.
I.e. What error messages are you getting.
One frequent problem the come up with make is addressed at the following
http://www.delphigroups.info/3/8/36427.html