In my qmake-pro-file, I use something like SOURCES = $$files(*.cpp) which expresses exactly what I want and works great when I do qmake && make. However, when I work with QtCreator and when I add or rename some file, how can I get QtCreator to update the file list? I currently must restart QtCreator.
AFAIK, the only ways you can force qt-creator to re-parse the pro file is by either touching the pro file (i.e. $ touch project.pro), or by re-saving the pro file (i.e. by adding a random space somewhere, removing it again and saving the file).
Related
I accidentally discovered that I can't edit any files that end in .lrp using vi. This is the case on OS X (High Sierra), on Ubuntu 16.04 as well as on Debian. Haven't tried any others, but this seems to occur on all of my colleagues machines as well. It's not a .vimrc setting by the looks of it either.
To reproduce, simply try to create or edit any arbitrary filename in vi, the filename needs to end in .lrp.
vi starts, but then has a red bar at the bottom stating:
***error*** (tar#Browse) File not readable<...path to file...>
Can anyone shed some light on this highly confusing matter?
Edit 1: I just wanted to add that this really sucks if you're stuck with a software package that has config files ending in .lrp you need to frequently edit manually. I can work around it creating a symlink, but that's not a nice option.
Edit 2: went through the vim sourcecode at github and stumbled across one line in this file runtime/autoload/tar.vim that declares .lrp files to be tar files... I've been around the block a few times yet never even heard of this. Perhaps an autoload option that can be disabled? my vimrc doesn't load any tar extensions or anything to would point that way.
Vim believes this file ending is a package of "Linux Router Project", which is compressed. Vim will try to open it with tar.
If you don't need this feature, you can disable this plugin completely.
let g:loaded_tarPlugin = 1
let g:loaded_tar = 1
Or open the file without autocommands
:noau e file-name.lrp
I have correctly downloaded and installed flex, bison and Dev C++ in C:\ . Then I tried to compile myfile.l in command prompt, but it gives the error:
flex: can't open myfile.l.
What is the problem?
I can see from your question that you are a beginner in need of some instruction, so what follows is in tutorial style. I hope you don't mind the tone. Many of my students encounter the same problem as you did when first starting.
The files containing the code for flex, bison or the compiler gcc (or g++) are just text files, and not some specially encoded form of file. They are only named something.l, something.y and something.c (or something.cpp) by convention. We could just call them something.txt or even something.l.txt if we wanted to. The reason they are named the way they are is to enable all the different components of one program to be distinguished without cluttering up the name space. So, if we have a project, such as some homework done in flex and bison, we can use the word homework as the base name and have the following file set:
homework.l <-- The lexer source file for flex created for the homework
homework.y <-- The parser source file for bison created for the homework
homework.cpp <-- The C++ source file for g++ created for the homework
homework.obj <-- The object file created by g++
homework.exe <-- The final windows executable created by g++
(There will be many other files as well, but I'll skip over that for now).
As the source files are just forms of a text file they can be created by a text editor. You indicated you are using Dev C++ which is an IDE (Integrated Development Environment) which combines a text editor, a compiler and a debugger into one package. The text editor part works just like any other text editor, such as Notepad, NotePad++, vim, emacs or one of the myriad of other editor tools.
Commonly, by default, a text editor tool on Windows will save a text file with the postfix language code of .txt. Here is an example dialogue of saving such a file:
You can see that if I saved my file, which I called SOlexer.l by pressing the Save button, I would get a file called SOlexer.l.txt because the default is to always make a file withe the suffix of .txt.
Now this does not need to be a problem. If I tried to invoke flex, as you did:
$ flex SOlexer.l
flex: can't open SOlexer.l
I would get the same error message. However I can just call flex with the actual file name used and it would work:
$ flex SOlexer.l.txt
$
Alternatively, I could rename the file, and then use it:
$ rename SOlexer.l.txt SOlexer.l
$ flex SOlexer.l
$
Problem solved!
However, as you have discovered, it is best to just create the file with the desired (and more convenient) name in the first place. To do this one has to just make a different selection from the menu when saving the file, like this:
If we click on All types (*.*) we can create the file without the .txt suffix. This should work for most similar tools also.
To help my students who had difficulty using flex and bison on Windows I made a series of video tutorials. You are welcome to use them also.
In conclusion, although you had trouble getting your flex file to build, your problem is nothing to do with flex or bison, but a simple beginners problem with learning how to create and edit files on a Windows system.
First of all, I would like to apologize if I'm on the wrong stackexchange network, and secondly, sorry if I'm overlooking something simple.
I was moving files from my old hard drive from an old PC when I came across several password protected ZIP Files. However, since those files were a bit old, I forgot the passwords already. I tried every password I could come up with but I still came up empty. After several google searches, I found this tool/utility for Mac OS X that could help me. So I go to the downloads page and download the Mac OSX utility tool and the source code.
However, I am having problems executing the make command for the file. It says on the downloads page:
If you are using linux or another unix, you need to download the source code, uncompress it and type "make" to compile the utility.
So far, what I've tried is
$make /Users/myname/Downloads/aapr-0.01-source/Makefile
I have also tried the other files in the source folder but nothing worked. After that, I'm pretty much blank. I tried double clicking the aapr file in the utility download for Mac (which is a Unix Executable) and it opens a new terminal window displaying the commands and such. Also, doing $aapr [options] [filename] only shows me -bash: aapr: command not found. I also updated XCodes command line tools.
Sorry if I'm missing out on something very basic, I don't usually use the terminal on the OS X.
Try running
cd /Users/myname/Downloads/aapr-0.01-source
make
A Makefile contains rules for building files from other files but it is based on paths and contents, etc. which depend on your current location. So generally you need to be in the directory of the project for it to work.
Edit (copied from my comment):
To execute a command from a specific location (that isn't in the normal $PATH) you need to specify a path for it. So something like /bin/bash or ./aapr (where ./ means the current directory).
I used addpath(pwd) to get my .m files working in my projects directory. When I close the window and start a new window, the path I just added is gone. But the files still run.
Is it in my path or not? How do I see the directories I have added to my path?
Also, . is the first entry I see from path. Does that mean I don't need to add any directories because it will always search the current directory first?
Thanks.
Basically, yes.
You can add a directory to the search path using addpath(), but as you know, it only exists for the current session and is reset when you restart Octave. If you want a path to survive between sessions, add it to your octaverc, a script file that gets run whenever a new session gets started. Example path to octaverc file is:
C:\Octave\3.2.4_gcc-4.4.0\share\octave\site\m\startup
Since . is in your path by default, Octave will search your current directory for any function files that it needs. Using addpath(pwd) is somewhat useless if you're just going to stay in the same directory. However, there are some cases where it'd be useful, if for example you have a directory that contains your functions, and another one that has the data that you're working on: you could start in the functions directory, do addpath(pwd), and then cd to the data directory while still being able to use your functions.
You can create batch file, which will start Octave with your directory path. Please see example below:
octave-3.6.4.exe -p "C:\MyOctaveDiretory"
-p means addpath()
addpath(pwd); savepath();
Done.
I think there is a bug in Octave (I use version 4.0.3 on Windows). When I create a new file in current path, this can't be called by Octave ("error: 'foo' undefined near line 1 column 1"). If I restart Octave, it works. This addpath(pwd) trick helps me a lot (before I unsuccessfully tried rehash() and cd elsewhere and back again).
If you had the same problem, the reason for the symptom might be:
Start Octave.
Create newfile.m.
Call newfile - fails since Octave did not register its existence.
addpath(pwd) - causes Octave to register it.
Close Octave
Start Octave - now pwd is gone from path, but newfile.m is registered at startup.
call newfile - works
I faced a similar problem in adding path where the path was added by using addpath command directly in Octave GUI (Command Window). The path added was being shown in console window but none of the functions worked.
The problem was solved by changing the path directory from Windows directory to some other direction where OS is not installed.
Heading says it all really. Using Windows 7 and latest stable gvim, whenever I save (:w) a file it's marked executable. I'm doing cross-platform development and it'd be nice if this didn't happen.
#sceptics: The flag of the files are indeed set as executable. Do a ls -al before and after re-saving the file to observe the issue. (install cygwin, or may be other *nix emulations)
#OP: the question have been raised several times in the past. I don't remember the conclusion on the subject. You should search vim mailing-lists archives (vim_use and vim_dev).
May be you can try to add an hook to your RCS (if it supports that) to proceed to a chmod -x on file extensions that does not correspond to an executable (*.h, *.cpp, *.vim, ...), or on files that do not contain a shebang (unlike perl, I don't know if python source files may contain a shebang)