The problem is that when I'm lauching dev-server through Kubuntu's Konsole app, debug output is colored:
But wher I'm launching it trough built-in "Run" or "Debug" in PyCharm, the output in PyCharm's console is all red:
Is there a way to make output in PyCharm colored? Because I can't find anything related in Settings.
UPD: link to issue on PyCharm issue tracker
As I see some people woting on this question, so here is the link to this issue on PyCharm issue tracker - youtrack.jetbrains.com/issue/PY-19790. If you will vote for this feature, it will be released faster!
Some time ago I wrote a code snippet that does the thing for me. It's not a perfect solution, but does the trick. BSD License
To use it:
Option 1: git clone/download this and import it somewhere (e.g. django development settings). Read the module docstring and the readme for details.
Option 2: include the code snippet below into your django development/debug settings (or anywhere else, where it will be run early). It's automatically verified with SHA-2 against file changes.
try: # Colored logger CaaS. Auto downloaded and verified.
import os
import hashlib
from urllib import request
url, sha256 = "https://lab.it.hs-hannover.de/lukyanch/pydevutils/raw/c531eaf7/colored_logger.py", "083e1a39cfdbe17a7126188b5477fb8f324be8106a39ed4a00faeb3f18c5aedc"
cached_file = "/tmp/{0}.py".format(sha256)
code = bool(os.path.exists(cached_file) or [request.urlretrieve(url, cached_file), print("Downloaded: " + url)]) and open(cached_file, "r").read()
assert hashlib.sha256(code.encode()).hexdigest() == sha256, os.remove(cached_file) or "Bad content: " + cached_file
exec(code)
except Exception as e:
print("No colored logger: {e.__class__.__name__}: {e}".format(e=e))
"grep console" is the plugin which handles this perfectly:
https://plugins.jetbrains.com/plugin/7125-grep-console
This is because the development console for PyCharm is not using the same kind of standards to display colors as your normal shell terminal (they are two very different things).
The output console for PyCharm is just a display of commands (its not a full shell with all the bells and whistles of your local terminal emulator).
You can embed a terminal into PyCharm (see the documentation on how to set it up) but doing so will not allow you to redirect the output of the built-in run commands to the terminal window. It will enable you to run arbitrary shell commands there, and avoid having to switch over to a terminal console.
Keep in mind if you have any special shell customization or fonts/glyphs these may not appear correctly in the embedded terminal, because it is using a different set of fonts and configuration.
You can try and raise this as an enhancement at the PyCharm bug tracker; if it gets enough votes it may make it in to the next release.
Related
I'm currently developing an application with QT 4.8 with a "Launch on login" option. My main problem currently is that I can't seem to find a proper way to make the program launch itself after login on Linux (Fedora 20 in my case).
My program should be able to run in the background without stopping fedora to launch.
I would also like to avoid having to ask for any sort of admin privilege since my application doesn't require any (except maybe for this option).
Finally found out about "home/.config/autostart/.desktop".
I'll have to create autostart if it's not created but from there I can chose to make or delete the file depending on what my user decided to do.
The .desktop file have to follow a particular syntax (which is not a problem for me)
[Desktop Entry]
Type=Application
Exec=</path/to/binary or command to execute>
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name=<Name_to_be_displayed>
Comment=<optional comment>
In my case, I can just remove the "comment" line since just the name of the application should be enough for the user to recognize it.
You can Either keep your executable in side /etc/rc.d/rs or inside /etc/init.d folder, so that it can automatically start once device is up.
Hope this Helps.
Each user has a .bashrc file located in their home directory, you could append a command to run your application to the end of that.
That will run when only that user logs in (I think either with graphical or terminal session)
To run for all users, look at creating a systemd service if you dare, or append a line to the end of /etc/rc.local. You'll need to be root for that though.
EDIT: Don't forget to put an ampersand at the end of the command to run in background.
When i tried to run following python code:
setlocale(locale.LC_ALL,"")
print getlocale()
The result is that it works fine if i run the script from Terminal.
But in eclipse/pydev with the same python compiler(python 2.7),it always return (none,none), any idea?
As you have already guessed from our conversation in the comments, this behavior is related to the environment. If you run Eclipse from the Terminal, you will get the same results you get when running Python directly from the Terminal.
So, your program is actually working fine. Depending on what you want to do, you don't need to worry about anything.
However, if you want to reconfigure your environment (system-wide or for all programs launched from the GUI, for example), you can do that in the appropriate files, using this answer as a guide.
For example, you may want to set the variables LANG and LC_ALL in one of those files, mimicking the configuration that is shown when you run the command locale from the Terminal. Assuming you want en_US with UTF-8, that added lines would look like:
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
I'm trying to work out how to run the debug stuff that pycharm seems to offer (well, it allows me to set breakpoints, anyway, so i'm assuming there's a nice gui for it)
I've concluded that i cannot use the ctrl-shift-r and then "runserver" command, and that instead i'd need to setup a "run configuration"? I made a "django server" one, but i don't know what values to put etc. When i run it, it tells me that some setting is wrong - i'm pretty sure it isn't, because the standard "runserver" command works fine.
And that's about all i concluded. If there is a nifty tutorial or steps to get it so i can
put in a break point
go to the page that triggers that breakpoint and follow the code's inner working in pycharm
i'd be thrilled!
cheers!
UPDATE: in case you're wondering, here is the error i got:
Traceback (most recent call last):
File "manage.py", line 11, in
import settings
File "C:\development\PycharmProjects\dumpstown\settings.py", line 185, in
add_to_builtins('gravatar.templatetags.gravatar')
File "C:\development\python\lib\site-packages\django\template\base.py", line 1017, in add_to_builtins
builtins.append(import_library(module))
File "C:\development\python\lib\site-packages\django\template\base.py", line 963, in import_library
raise InvalidTemplateLibrary("ImportError raised loading %s: %s" % (taglib_module, e))
django.template.base.InvalidTemplateLibrary: ImportError raised loading gravatar.templatetags.gravatar: Settings cannot be imported, because environment variable DJANGO_SETTINGS_MODULE is undefined.
Where the application itself, on a "runserver" never has any issues.
UPDATE: as per my answer below, pycharm is broken for add_to_builtins.
The problem has little to do with DJANGO_SETTINGS_MODULE. Pycharm sets this when creating the project. Instead Go to the little green "Play button" for running scripts. You want to configure it to run manage.py, ie you are configuring the play button to run the command python manage.py runserver.
Breakdown:
python------> run with python Intepreter
manage.py--------> run this script
runserver---------> arguments
So go to the drop down to the left of the green play button
,
click on edit configurations. You will get a screen like this one
.
Fill it out as shown locating your manage.py source script. Make sure you include runserver on the arguments box. Now you can click the green debug button and you program will stop at the first breakpoint it ecounters allowing you to descend upon it in full debug mode watch variables and all. Now you can manually type python manage.py runserver on the terminal or use your newley configured run button.
Setup your virtual environment
Create or open your project in PyCharm
Go to File - Settings in the menu (or just click on the settings icon)
Go to Python Interpreter
Click on Add in the top
Go to the bin folder where you created the virtual environment and select python
Set a breakpoint
Next to the line of code you want to set the breakpoint. To the left there is usually a grey line. Usually next to the line numbers. Just click there and a big red dot will appear. Looks like this
Hit the Run in debug mode button.
Next to the Green play button there is a button with a bug on it. Use that to launch the runserver in debug mode. Now when you use your web application and the code hits the breakpoint it will stop there and you will be able to step in and over or resume in pycharm.
If you still are not able to debug you might need to edit the pycharm project config. You can do that like this.
You can look at http://garmoncheg.blogspot.it/2012/01/establishing-dev-environment-with.html too
So i gave all the answers here a +1 for trying - but they're not the issue. Near as i can tell, the answer is that pycharm is broken. Which is a pain, but the solution is easy -
IF you dont' want to use the little green button at the top of pycharm, or use the pycharm debugging feature? then don't worry, you don't need to do anything. Continue using ctrl-shift-r and runserver (or whatever your shortcut to manage.py is)
IF you do want to use the little green "run" button, or if you want to use pycharm's debugging kit, then you absolutely cannot use the "add_to_builtins", at least in the settings.py file (I never put it anywhere else myself, pycharm might require it elsewhere?). add_to_builtins doesn't work in pycharm - it gets itself caught in a loop of grave consequences when you use the little green button or the debug button. Using ctrl-shift-r and runserver doesn't, curiously, have this problem.
The good news is that "add_to_builtins" isn't a must-have, just a nice-to-have. Just add the "{% load x %}" command to each template where you use x and you will be set.
Alternatively, save a hundred bucks and use some sort of free eclipse tool.
The problem is that the DJANGO_SETTINGS_MODULE variable which should point to your project's settings file, wasn't set anywhere, since the variable is reported to be undefined.
The solution and an explanation you can refer to can be found in a previous post
A while ago I changed my personal operating system to linux and my development enviroment to KDevelop.
However debugging c++ projects is still not working as it should.
My KDevelop version is 4.2.2 (I installed it through package management)
Every time I hit the "debug button" the application is starting with the console message
warning: GDB: Failed to set controlling terminal: Operation not permitted and debugging functionality is not available.
Any ideas welcome.
(If you need additional information don't hesitate to ask)
I also had this problem, but I use gdb in KDevelop sparsely enough that hadn't bothered me yet. Here's my log of trying to fix it:
Grepping through the GDB 7.3.1 source code reveals that this message is printed when GDB tries to set its master TTY to a newly-created pseudo-tty (see gdb/inflow.c, lines 683-740). In particular, a call to ioctl with request TIOCSCTTY fails with a permissions error.
With this in mind, I took a look at the Linux kernel source code to see what could cause a failure. A bit of searching shows that it will eventually degenerate into a call to tiocsctty(). The comment from tiocsctty that is important here:
/*
* The process must be a session leader and
* not have a controlling tty already.
*/
Since the only other reason it can fail with EPERM is if the tty that GDB creates is actually a controlling tty for another process (which seems highly unlikely), I thought it reasonable to assume that GDB is not a session leader. Fair enough, it's launched by KDevelop after all!
So: I tried not launching the GDB session in an external terminal, and it works. Problem narrowed down.
Originally, the external terminal line was set to konsole --noclose --workdir %workdir -e %exe. Changing this to terminator -e %exe made a slight difference: KDevelop warned me that
GDB cannot use the tty* or pty* devices.
Check the settings on /dev/tty* and /dev/pty*
As root you may need to "chmod ug+rw" tty* and pty* devices and/or add the user to the tty group using "usermod -G tty username".
I checked my permissions; my user was part of the tty group and all relevant files were readable and writable.
Grepping through the KDevelop source code reveals how KDevelop actually sets up the terminal. It runs the shell script
tty > FIFO_PATH ; trap "" INT QUIT TSTP ; exec<&-; exec>&-; while :; do sleep 3600;done
and then sets up GDB to use the terminal device it reads from FIFO_PATH. (My name, by the way, not the one that KDevelop uses.) The problem (as best I can tell) is that gdb is not launched as a child of the shell script, and thus cannot use it as its main tty.
I'm not feeling up to patching KDevelop to make this work properly as of yet (or finding what actually caused this to stop working in the first place . . .), so the best I can suggest at the moment is to simply not use an external terminal for debugging purposes.
Good luck! I'll update if I find anything useful.
As Arthur Zennig said, for more information, you need to do something
Firstly, you need to create the Terminal profile
Secondly, open Launch Configurations, fill info such as the image below
Good luck!
In case you got the error:
"Can't receive konsole tty/pty. Check that konsole is actually a
terminal and that it accepts these arguments"
RUN > CONFIGURE LAUCHERS > (See picture below. My project name was "loops")
What worked for me was to uncheck checkbox "Use External Terminal". Found the in the "Compiled Binaries" Tab.
Using Eclipse and CDT to debug C++ code the variable windows is cumbersome and not very informative for types defined in the standard template library or in boost (e.g. shared_ptr).
Just an example how this may look like for an std::vector:
bar {…}
std::_Vector_base<TSample<MyTraits>, std::allocator<TSample<MyTraits> > >
_M_impl {…}
std::allocator<TSample<MyTraits> > {…}
_M_start 0x00007ffff7fb5010
_M_finish 0x00007ffff7fd4410
_M_end_of_storage 0x00007ffff7fd5010
Even if this information about the internals of those types may be useful, in almost any cases I would expect a clearer presentation here, i.e. a list of values for the std::vector. Are there any tools, plugins or other modifications around which can do this?
EDIT
The following solutions does not work for linux. I am using ubuntu 14.04, eclipse, g++, gdb.
I cant find a package gdb-python and linux does not use mingw
You need a version of GDB capable of using python to pretty print structures. I know at least on windows using mingw that this is not provided in the default install.
Pretty Printers are python modules which tell gdb how to display a given structure. You can write your own, but there are already printers for STL available for download.
To Get Pretty Printers working on Windows (instructions should be similiar for other OS's):
Prerequisites
Make sure you have you have Python 2.7 installed and in the system path.
http://www.python.org/download/
Make sure MinGW-get is installed
http://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst/
Make sure you have an SVN client are installed
Installation:
Open a command Shell and type:
mingw-get install gdb-python
When its finished cd to a local directory and install the printers by typing:
svn co svn://gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/python
Open the .gdbinit (create it in a text editor if need be) and type the following replaceing "C:/directory" with the folder that you checked the printers into.
Python
import sys
sys.path.insert(0, 'C:/directory')
from libstdcxx.v6.printers import register_libstdcxx_printers
register_libstdcxx_printers (None)
end
Eclipse Setup
Go To Windows > Preferences > C/C++ > Debug > GDB
Where it Says GDB Debugger put the path to the python enabled GDB it will most likely be in the mingw /bin folder with a name like gdb-python27.exe
Where it says GDB Command File put the path to the .gdb init file you made earlier.
That's it, debug like normal, the stl structures should be much easier to read.
Well, gdb don't natively support STL containers. You can't say this is incorrect, since it will expose the inner workings of the STL objects, but most of the time it is not what we want, right?
If you're using gdb 7.0 you can take advantage of the pretty printers. This website http://sourceware.org/gdb/wiki/STLSupport has a pretty simple tutorial on how to set them. I copied below the part that interests you:
Check-out the latest Python libstdc++ printers to a place on your
machine. In a local directory, do:
svn co svn://gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/python
Add the following to your ~/.gdbinit. The path needs to match
where the python module above was
checked-out. So if checked out to:
/home/maude/gdb_printers/, the path
would be as written in the example:
python
import sys
sys.path.insert(0, '/home/maude/gdb_printers/python')
from libstdcxx.v6.printers import register_libstdcxx_printers
register_libstdcxx_printers (None)
end
The path should be the only element
that needs to be adjusted in the
example above. Once loaded, STL
classes that the printers support
should printed in a more
human-readable format. To print the
classes in the old style, use the /r
(raw) switch in the print command
(i.e., print /r foo). This will print
the classes as if the Python
pretty-printers were not loaded.
Since you're using eclipse cdt, don't forget to point your debug configuration to your .gdbinit file. When creating a new Debug Configuration, go to the Debugger tab and put the path to the .gdbinit file in the "GDB command file" field.
I hope that helps!
In debug view in variables list expand vector:
"vector_name" -> std::_Vector_base<"datatype"> -> _M_impl
then right click on _M_start and select "Display as array...", type its length and then click OK. Now you can expand each item of your vector.
If you have gdb support for CDT (see, for example, GDB in Eclipse), you could try this: De-referencing STL containers
Long ago I also stumbled upon your same problem. It was a pain to check the STL containers. Then I found that link and added to my .gdbinit file some of those definitions. Life was easier after that.
NOTE: My gdb version is 7.1 and adding those definitions work fine. I don't know if in newer versions of gdb they are already included.
I would like to expand on the Windows 7 response because some key steps are left out:
This is for MinGW users with Eclipse CDT
0) If you don't have python GDB, open a shell/command and use MinGW-get.exe to 'install'
Python-enabled GDB e.g.
MinGw-get.exe install gdb-python
1a) Get Python 2.7.x from http://python.org/download/ and install
1b) Make sure PYTHONPATH and PYTHONHOME are set in your environment:
PYTHONPATH should be C:\Python27\Lib (or similar)
PYTHONHOME should be C:\Python27
1c) Add PYTHONHOME to your PATH
%PYTHONHOME%;...
2a) Open a text enter, enter the following statements. Notice the 3rd line is
pointing to where the python scripts are located. See notes below about this!
python
import sys
sys.path.insert(0, 'C:/MinGW/share/gcc-4.6.1/python')
from libstdcxx.v6.printers import register_libstdcxx_printers
register_libstdcxx_printers (None)
end
2b) Save as '.gdbinit' NOTE: Windows explorer will not let you name a file that starts with
with a period from explorer. Most text edits (including Notepad) will let you. GDB init
files are like 'scripts' of GDB commands that GBD will execute upon loading.
2c) The '.gdbinit' file needs to be in the working directory of GDB (most likely this is
your projects root directory but your IDE can tell you.
3) Open your Eclipse (or other IDE) Preferences dialog. Go to the C++ Debugger sub-menu.
4) Configure Eclipse to use C:\MinGW\bin\gdb-python27.exe as the debugger and your .gdbinit as the config file.
5a) Re-create all your debug launch configurations (delete the old one and create a new one from scratch).
--OR--
5b) Edit each debug configuration and point it to the new gdb-python.exe AND point it to the.
If you run into issues:
--Don't forget to change the location to the python directory in the above python code!
This directory is created by MinGW, so don't go looking to download the pretty printers, MinGW
did it for you in step zero. Just goto your MinGW install director, the share folder,
the GCC folder (has version number) and you will find python folder. This location is what
should be in python script loaded by GDB.
--Also, the .gdbinit is a PITA, make sure its named correctly and in the working folder of GDB
which isn't necessarily where gdb-python.exe is located! Look at your GDB output when loading GDB to see if a) 'python-enabled' appears during load and that the statements in the .gdbinit are appearing.
--Finally, I had alot of issues with the system variables. If python gives you 'ImportError' then most likely you have not set PYTHONPATH or PYTHONHOME.
--The directory with 'gdb-python27' (e.g. C:\MinGW\bin') should also be on your path and if it is, it makes setting up eclipse a bit nicer because you don't need to put in absolute paths. But still, sometimes the .gbdinit needs an absoulte path. if it works you'll see output from gbd (console->gdb traces) like this on startup of debugger:
835,059 4^done
835,059 (gdb)
835,059 5-enable-pretty-printing
835,069 5^done
....
835,129 12^done
835,129 (gdb)
835,129 13source C:\MinGW\bin\.gdbinit
835,139 &"source C:\\MinGW\\bin\\.gdbinit\n"
835,142 13^done
835,142 (gdb)
I know that JDT (Java environment in eclipse) provides custom "formatters" to be applied when displaying variable values in debug views. A quick look at google for the same in CDT brings this page:
http://wiki.eclipse.org/CDT/Better_Debugging_%28GSoC_project%29
I don't know if this has been yet integrated in the main CDT line, may be you can try to right click on a variable while debugging (in the last CDT) and see if there is a custom formater entry. If not available I recomend you to add a new tracker entry in CDT tracker to ask this enhancement.