On Windows, IPython is the easiest-to-use command-line environment I have available. In my really old IPython environment (Python 2.7.5, IPython 0.13.2, and pyreadline 2.0), I used to be able to type a partial file path at the command line, press tab, and get something like this:
In [1]: cd /Users/Jez/D
/Users/Jez/Desktop/ /Users/Jez/Downloads/ /Users/Jez/dots2-default-accel=6da3a.pdf
/Users/Jez/Documents/ /Users/Jez/Dropbox/
All of the options it presents are bona-fide files and directories. That's good.
With a newer setup (Python 3.6.4, IPython 6.1.0, (py)readline???) the following happens:
In [1]: cd /Users/Jez/D
delattr() dir() /Users/Jez/Desktop/ /Users/Jez/Dropbox/
DeprecationWarning display() /Users/Jez/Documents/
dict divmod() /Users/Jez/Downloads/
Despite the fact that what has been typed so far is only meaningfully interpretable as a filesystem path, the completion options include a whole lot of things that aren't files or directories (as if I might want to divide a non-existent object called /Users/Jez by something). This is less smart. I find it quite frequently derails my train of thought (in this example there are only 6 false positives, but sometimes there are so many that the bona-fide options are completely hidden).
Is there a configuration option somewhere that can allow me to re-capture the specificity of the old behaviour? My search-foo has failed me so far - I've found a few references to readline and .inputrc but I suspect that's irrelevant for Windows.
Got it:
%config IPCompleter.use_jedi = False
or equivalently in /Users/Jez/.ipython/profile_default/ipython_config.py:
c = get_config()
...
c.IPCompleter.use_jedi = False
Order 66 complete. What a relief.
Related
I'm using Buildroot as a submodule, and I want to reuse existing in-tree defconfigs with a few modification of my own.
I'd like to store just the modified options in a config fragment, just like I can do with BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES for the Linux kernel config.
Right now I'm doing something like:
cd buildroot
make BR2_EXTERNAL="$(pwd)/../mypackage" qemu_x86_64_defconfig
echo '
BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES="../kernel_config_fragment"
BR2_ROOTFS_OVERLAY="../rootfs_overlay"
' >> .config
make
Is there a nicer way to avoid that echo with a config fragment, just like I'm using for the Linux kernel config fragment? I'd expect something like:
make BR2_CONFIG_FRAG=br_config_frag
where br_config_frag contains the lines:
BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES="../kernel_config_fragment"
BR2_ROOTFS_OVERLAY="../rootfs_overlay"
and then I'd be able to write just:
make -C buildroot BR2_CONFIG_FRAG=br_config_frag qemu_x86_64_defconfig all
Here's the full example repo.
Edit
One slight improvement is to put the "config fragment" in a separate file buildroot_config_fragment:
BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES="../kernel_config_fragment"
BR2_ROOTFS_OVERLAY="../rootfs_overlay"
and then cat that:
cat ../buildroot_config_fragment >> .config
First side note: your script should run make olddefconfig before make, so that any new options are set to their default value instead of being asked for interactively.
You could simplify the script a little by doing:
cat configs/qemu_x86_64_defconfig br_config_frag > .config
make olddefconfig
You can also use the script support/kconfig/merge_config.sh from the kconfig infrastructure. However, that script internally uses make alldefconfig which currently doesn't work - you need a patch for that.
If you would like to add support for BR2_CONFIG_FRAG to the Buildroot infrastructure, feel free to send a patch to the Buildroot mailing list!
I asked on the IRC, and an user who seems to be Yann E. Morin, who seems to be an active developer, said it is not possible currently.
Arnout's make alldefconfig patch is now merged in buildroot as of 26 Jul 2017
(https://github.com/buildroot/buildroot/commit/dab80981d15979eab3aea28a33694396635a52a1).
This means you can now do:
./support/kconfig/merge_config.sh configs/qemu_x86_64_defconfig fragment1.config fragment2.config
This will use qemu_x86_64_defconfig as the base and add modifications given in the listed fragment config files. The tool will also show nice warnings if you override items.
I am stuck with this incredibly silly error. I am trying to run pytest on a Raspberry Pi using bluepy.
pi#pi:~/bluepy/bluepy $ pytest test_asdf.py
============================= test session starts ==============================
platform linux2 -- Python 2.7.9, pytest-3.0.7, py-1.4.33, pluggy-0.4.0
rootdir: /home/pi/bluepy, inifile:
collected 0 items / 1 errors
==================================== ERRORS ====================================
______________ ERROR collecting bluepy/test_bluetoothutility.py _______________
ImportError while importing test module '/home/pi/bluepy/bluepy/test_asdf.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
test_asdf:4: in <module>
from asdf import AsDf
asdf.py:2: in <module>
from bluepy.btle import *
E ImportError: No module named btle
!!!!!!!!!!!!!!!!!!! Interrupted: 1 errors during collection !!!!!!!!!!!!!!!!!!!!
=========================== 1 error in 0.65 seconds ============================
I realised that my problem could be that rootdir is showing incorrect path. It should be
/home/pi/bluepy/bluepy
I've been reading pytest docs but I just do not get it how to change the rootdir.
Your problem is nothing to do with Pytest's rootdir.
The rootdir in Pytest has no connection to how test package names are constructed and rootdir is not added to sys.path, as you can see from the problem you were experiencing. (Beware: the directory that is considered rootdir may be added to the path for other reasons, such as it also being the current working directory when you run python -m pytest.)
The problem here, as others have described, is that the top-level bluepy/ is not in sys.path. The easiest way to handle this if you just want to get something running interactively for yourself is as per Cecil Curry's answer: cd to the top-level bluepy and run Pytest as python -m pytest bluepy/test_asdf.py (or just python -m pytest if you want it to discover all test_* files in or under the current directory and run them). But I think you will need to use python -m pytest, not just pytest, in order to make sure that the current working directory is in the path.
If you're looking to set up a test framework that others can easily run without mysterious failures like this, you'll want to set up a test script that sets the current working directory or PYTHONPATH or whatever appropriately. Or use tox. Or just make this a Python package using standard tools that can run the tests for you. (All that goes way beyond the scope of this question.)
By the way, I concur with Cecil's opinion of Mackie Messer's answer; messing around with conftest.py like that is overly difficult and fragile; there are better solutions for almost any circumstance.
Appendix: Use of rootdir
There are only two things, as far as I'm aware, for which rootdir is used:
The .pytest_cache/ directory is stored in the rootdir unless otherwise specified (with the cache_dir configuration option).
If rootdir contains a conftest.py, it will always be loaded, even if no test files are loaded from in or under the rootdir.
The documentation claims that the rootdir also used to generate nodeids, but adding a conftest.py containing
def pytest_runtest_logstart(nodeid, location):
print("logstart nodeid={} location={}".format(nodeid, location))
and running pytest --rootdir=/somewhere/way/outside/the/tree shows that to be incorrect (though node locations are relative to the rootdir).
My first guess would be that you don't have that directory in the python path. You can add it to the python path dynamically. One simple way to do this is in a test configuration file conftest.py, which I believe is always executed before test discovery and test running.
For example, you might have a project setup like:
root
+-- tests
| +-- conftest.py
| +-- tests_asdf.py
+-- bluepy (or main project dir)
| +-- miscellaneous modules
In which case, you could add the root dir to your python path in the conftest.py file like so:
#
# conftest.py
import sys
from os.path import dirname as d
from os.path import abspath, join
root_dir = d(d(abspath(__file__)))
sys.path.append(root_dir)
Let me know if that's helpful.
Actually, py.test is correctly discovering the rootdir for your project to be /home/pi/bluepy. That's good.
Tragically, you are erroneously attempting to run py.test within your project's package subdirectory (i.e., /home/pi/bluepy/bluepy) rather than within your project's rootdir (i.e., /home/pi/bluepy). That's bad.
Let's break this down a little. From within the:
/home/pi/bluepy directory, there is a bluepy.btle submodule. (Good.)
/home/pi/bluepy/bluepy subdirectory, there is no bluepy.btle submodule. (Bad.) Unless you awkwardly attempt to manually inject the parent directory of this subdirectory (i.e., /home/pi/bluepy) onto sys.path as Makie Messer perhaps inadvisably advises, Python has no means of inferring that the package bluepy actually refers to the current directory coincidentally also named bluepy. To avoid ambiguity issues of this sort, Python is typically only run outside rather than inside of a project's package subdirectory.
Since you ran py.test from the latter rather than the former directory, Python is unable to find the bluepy.btle submodule on the current sys.path. For this and similar reasons, py.test should typically only ever be run from your project's top-level rootdir (i.e., /home/pi/bluepy):
pi#pi:~/ $ cd ~/bluepy
pi#pi:~/bluepy $ py.test bluepy/test_asdf.py
Lastly, note that it's typically preferable to defer test discovery to py.test. Rather than explicitly listing all test script filenames on the command line, consider instead letting py.test implicitly find and run all tests containing some substring via the -k option. For example, to run all tests whose function names are prefixed by test_asdf (regardless of the test script they reside in):
pi#pi:~/ $ cd ~/bluepy
pi#pi:~/bluepy $ py.test -k test_asdf .
The suffixing . is optional, but often useful. It instructs py.test to set its rootdir property to the current directory (i.e., /home/pi/bluepy). py.test is usually capable of finding your project's rootdir and setting this property on its own, but it can't hurt to specify it manually. (Especially as you're having... issues.)
For further details on rootdir discovery, see Initialization: determining rootdir and inifile in the official py.test documentation.
Ok, so here's my issue. I have written a build script in bash that pipes output to tee and sorts different output to different log files (so I can summarize errors/warnings at the end and get some statistics on files built). I wanted to use the colorgcc perl script (colorgcc.1.3.2) to colorize the output from gcc and had found in other places that this won't work piping to tee, since the script checks if it is writing to something that is not a tty. Having disabled this check everything was working until I did a full build and discovered some of the code we receive from another group builds C dependency files (we don't control this code, changing it or the build process for these isn't really an option).
The problem is that these .d files have the form as follows:
filename.o filename.d : filename.c \
dependant_file1.h \
dependant_file2.h (and so on for however many dependencies there are)
This output from GCC gets written into the .d file, but, since it is close enough to a warning/error message colorgcc outputs color codes (believe it's the check for filename:lineno:message but not 100% sure, could be filename:message check in the GCCOUT while loop). I've tried editing the regex to attempt to not match this but my perl-fu is admittedly pretty weak. So what I end up with is a color code on each line for these dependency files, which obviously causes the build to fail.
I ended up just replacing the check for ! -t STDOUT with a check for a NO_COLOR envar I set and unset in the build script for these directories (emulates the previous behavior of no color for non-tty). This works great if I run the full script, but doesn't if I cd into the directory and just run make (obviously setting and unsetting manually would work but this is a pain to do every time). Anyone have any ideas how to prevent this script from writing color codes into dependency files?
Here's how I worked around this. I added the following to colorgcc to search the gcc input for the flag to generate the .d files and just directly called the compiler in that case. This was inserted in place of the original TTY check.
for each $argnum (0 .. $#ARGV)
{
if ($ARGV[$argnum] =~ m/-M{1,2}/)
{
exec $compiler, #ARGV
or die("Couldn't exec");
}
}
I don't know if this is the proper 'perl' way of doing this sort of operation but it seems to work. Compiling inside directories that build .d files no longer inserts color codes and the source file builds do (both to terminal and my log files like I wanted). I guess sometimes the answer is more hacks instead of "hey, did you try giving up?".
I am trying to set a mapping for FileType perl. The mapping is for the case when I forgot to use semicolon at the end of the line.
So first I tried adding in my .vimrc autocmd! FileType perl nnoremap <leader>; $a;<esc> and it worked fine but than I thought of using ftlugin/perl.vim .
So I added the below line in my corresponding ~/.vim/after/ftplugin/perl.vim
nnoremap <buffer> <leader>; $a;<esc>
but it didn't work.
Any idea why it is not working ?
My perl version is perl 5, version 14.
Try putting the file in ~/.vim/ftplugin/perl.vim instead of ~/.vim/after/ftplugin/perl.vim. From :help after-directory:
*after-directory*
4. In the "after" directory in the system-wide Vim directory. This is
for the system administrator to overrule or add to the distributed
defaults (rarely needed)
5. In the "after" directory in your home directory. This is for
personal preferences to overrule or add to the distributed defaults
or system-wide settings (rarely needed).
From :help ftplugin:
If you do want to use the default plugin, but overrule one of the settings,
you can write the different setting in a script: >
setlocal textwidth=70
Now write this in the "after" directory, so that it gets sourced after the
distributed "vim.vim" ftplugin |after-directory|. For Unix this would be
"~/.vim/after/ftplugin/vim.vim". Note that the default plugin will have set
"b:did_ftplugin", but it is ignored here.
One thing I just noticed that was driving me crazy: <buffer> must be lowercase! Out of habit, I uppercase all of my <BRACKET> prefixes... and I had done the same for <BUFFER>. None of my ftplugin mappings worked and I couldn't figure it out... until I wasted hours trying different things, only to find that it must be lowercase <buffer>.
Can I find out from the MATLAB command line what is the installation path of specific program?
Or can I find the path for a registered program (Windows reg equivalent)?
This won't be 100% reliable, but this will get the right answer most of the time:
function p = findOnSystemPath(f)
p = '';
path = getenv('path');
dirs = regexp(path,pathsep,'split');
for iDirs = 1:numel(dirs)
tp = fullfile(dirs{iDirs},f);
if exist(p,'file')
p = tp;
break
end
end
Sample usage:
>> findOnSystemPath('runemacs.exe')
ans =
C:\Program Files (x86)\emacs\bin\runemacs.exe
Depending on your OS, you might be able to get this information from the system directly:
which is available on Unix systems and Windows systems with Cygwin installed:
>> [~,p] = system(sprintf('which "%s"',f))
p =
C:/Program Files (x86)/emacs-mw-a/bin/runemacs.exe
where is available on Windows 2003 and later:
>> [~,p] = system(sprintf('where "%s"',f))
p =
C:\Program Files (x86)\emacs-mw-a\bin\runemacs.exe
And in some cases, you can pull this information from the registry using winqueryreg, for example:
>> notepadEdit = winqueryreg('HKEY_CLASSES_ROOT','Applications\notepad.exe\shell\edit\command')
notepadEdit =
C:\Windows\system32\NOTEPAD.EXE %1
Call the DOS/bash command which, e.g.,
!which matlab
!which notepad
(Or use system instead of the !.)
EDIT: It seems that there isn't a direct equivalent in Windows. I had cygwin installed on the (Win XP) machine I tried it on, and the command succeeded. Alternatively, take a look at these answers on stackoverflow and superuser.
This depends on what you know about the OS and what properties your program has.
On Linux I usually do something like:
[error, path] = system(sprintf('which "%s"',programName));
It doesn't look pretty and it's far from portable (I suppose it will not work on Windows, perhaps only if you install Cygwin or something similar). It's far easier in Unix since most executables are accessible from the "path" (the environment variable "path"), while in Windows most executables are either stored in the Windows directory (which is in the default path, so they are found) or in a Program Files directory which is not as far as I recall.
Error = 0 when the program is found and path then obviously contains the path to the executable.
For Windows I guess you can search all directories for the program, but that might be somewhat tedious.
MATLAB is not really designed to be used as a tool to search files anywhere on the drive. That's a task best left to the OS, and what Egon suggested is what you should be doing. Simply replace which with the equivalent in DOS (you should know this already, else just ask another question in the MS-DOS/Windows tag. It probably has already been answered.).
If you are really hell bent on using MATLAB to search the drive, then you can do the following
addpath(genpath('C:\')); %#' I am not sure which way the slash is
which filename
Beware, the first step will take a while.