What are the differences between running Python code through an IDE and terminal? When I run my code in PyCharm it works, however when I try to run the same code in terminal I get NameError, etc.
An exact answer depends on the exact IDE and the exact terminal one compares on a particular OS. The IDLE doc chapter, accessible from IDLE's Help menu, has a section '3.3. IDLE-console differences '. Some of these apply to other IDEs.
One possible difference not discussed is language differences. IDLE runs user code directly with python, as is. Other IDEs add language extensions or command escapes.
Your issue with NameErrors suggests that PyCharm inserts something into globals that standard python does not. A few years ago, a couple of Stackoverflowers reported extra name issues with IDLE, which I fixed. For anyone to say anything more, you would have to add specific code and the resulting traceback to your question.
Related
I'm trying to write my first Shell extension and - as every blog post out there - I am too struggling with the lack of up-to-date documentation...
Namely I am trying to grab all key strokes from the keyboard, and - looking at code online and old mailing list messages - it seems that until recently the correct way of doing was:
const Shell = imports.gi.Shell;
global.set_stage_input_mode(Shell.StageInputMode.FULLSCREEN);
global.stage.connect('key-press-event', myCallbackHere);
However this doesn't seem to work. Both the function set_stage_input_mode and the property StageInputMode seem to have gone, at least on my Fedora 24 running GTK 3.20.6.
What is the correct, current way to have my extension grabbing all keystrokes performed by the user?
I don't think there is a correct way to do this at the moment. You could hack something together that is either X specific or Wayland specific or maybe you could patch Gnome Shell to provide this information.
For Wayland you could start at https://github.com/MaartenBaert/wayland-keylogger and for X you could start by looking at reusing the key detection from autokey (https://github.com/autokey/autokey/blob/master/src/lib/interface.py).
I can guess this is not the answer you were hoping for, because on IRC you wrote that you want to write a replacement for autokey. For getting input from an external program you can use GLib.spawn_async_with_pipes (https://people.gnome.org/~gcampagna/docs/GLib-2.0/GLib.spawn_async_with_pipes.html).
I wrote some time ago some Shell extension code to poll xinput test and log roughly what's happening (think any alphanumeric key vs left ctrl vs return key). You can look at that code here: https://gist.github.com/daniellandau/7679741bf8bbc5c345591593ca05e9f6. It's not robust enough for doing any kind of macro expansion so I'd recommend reusing the detection code from autokey.
In general the docs at https://people.gnome.org/~gcampagna/docs are the place to find API references for libraries usable from Gnome Shell extensions. I hope you get ahead with your project. Starting out writing extensions is frustrating but eventually very fun once you get the hang of it.
Whenever possible, I usually tend to learn keyboard shortcuts. It's really amazing to see an experienced coder works with VI effectively.
I've been trying for sometime switching to debugging with gdb, instead of eclipse debugger (based on gdb)
And I still find it hard to actually navigate through the code, inspecting variables, etc.
Actually, I have never seen an experienced gdb user, so I'm wondering... does it worth it? Is it possible to work effectively with gdb ?
Note: I also tried cgdb, which is a curses extension of gdb. It's better, but I still feel that its still not effective enough...
GDB has a curses interface, which can be activated via the command line option -tui.
This interface has a single key mode, which makes the most common operation available with a single keystroke. If additionally you make use of automatic command execution e.g. to display variable values, when a breakpoint is reached, then this is as comfortable and quick as it gets. But if you use Eclipse anyway, I see no point in avoiding the Eclipse UI for gdb.
I used GDB inside emacs for some time, but found the time to transfer information between GDB and emacs unacceptable, so I switched to this TUI mode mentioned above. I don't know, if the transfer of information between GDB and Eclipse is faster, but at least startup time of complex programs might be much better in GDB directly than in Eclipse.
You could also try the ddd debuger:
http://www.gnu.org/software/ddd/
This question didn't get much attention, although a bounty was offered.
So I decided to investigate further the issue for myself.
Finally I stumbled upon a solution which I think can be quite effective.
It's called tmux, and it's basically similar to gnu screen.
This tool allows splitting the console to several panes, each containing different process.
Therefore it's possible to have a single window with gdb and emacs.
switching between the windows is very easy using a dedicated hot key.
I would like to start programming in GO. As I am a Windows user, I understand that it possible to do so using the GO plugin for NetBeans.
Until now, I have written GO programs in text files and run them using the command prompt, but I prefer to use another platform/environment so I would be able to debug the programs.
The code examples in this forum are syntax highlighting and seem to be taken from an environment like Visual Studio. Does anyone know about the environment?
I would appreciate a simple solution. Thank you! :)
IDEs built specifically for Go and still actively maintained:
LiteIDE: http://code.google.com/p/golangide/
Portable and fast with build in debugger
GoWorks: http://tunnelvisionlabs.com/products/demo/goworks
Based on NetBeans 7.3, standalone application or NetBeans plugin
Googling you can find several IDE, for instance:
http://go-ide.com/ or
https://code.google.com/p/goclipse/
You may find this question gets closed as it's quite subjective, and a FAQ. However, the simple answer: from your description, it seems likely that you would be comfortable with goclipse.
More complete answer: there is no "one true environment" for Go development. The code examples you see here are coloured using Stack Overflow's syntax highlighter, and were submitted in plain text. You'll probably find highlighting and utilities available for most major editors. For example, I use Vim which has a plugin to run gofmt on the current buffer.
I believe some Windows users are fond of Sublime Text 2's GoSublime plugin. A more complete list of development tools can be found here.
You don't really need an IDE to develop using Go. I'd encourage you to spend more time working with a good editor and the command line. Getting to know the tools already distributed with the language is essential IMHO (go, godoc, gofmt). See also Debugging Go Code with GDB.
I am quite familiar with MATLAB, although not so much with writing GUIs in it. Now my boss gave me a MATLAB program with GUI which was developed on a Windows machine and runs there without problems. I copied it to my mac (osx 10.6.5 with MATLAB R2009b) using a USB memory stick and tried to work on the files on my computer.
When starting the GUI, some of the callbacks are executed, some not. I was able to open the figure file containing the GUI in GUIDE, but there cannot click on the callback fields in the Property inspector. Also some components are not shown in GUIDE which are visible when running the GUI. First I suspected it might be corrupted by changed newline characters, but learned that .fig files are binary, so this should not be the case. I opened the binary .fig file with a text editor and found the following ASCII line followed by binary data:
MATLAB 5.0 MAT-file, Platform: PCWIN, Created on: Tue Aug 10 17:11:57 2010
Are the GUIs created with MATLAB OS specific? Wouldn't this be really stupid?
I opened the files on the windows machine again and tried to export them or save them by specifying that I want them to be compatible with other operating systems but could not find an option like this.
Of course I researched this on google, and wondered that I did not really find something related. If an incompatibility exists, I think this would have been discussed, right?
Anyone knows about it or had the same problem before?
Hmmm, ok. Well, the answer is quite embarrassing but still bears some potential to learn from it. The folder that my boss gave me contained a lot of files and figures with similar names, like:
bla1.fig
bla.fig
bla0.fig
the simple problem was, the first time I opened the figure with GUIDE I opened figure bla.fig instead of bla1.fig. After this I always used the reopen function of GUIDE and did not see that it was always the wrong file. this caused the problems.
==> so there is no incompatibility between Mac and PC, although I wonder why the platform is written in the file then
==> it could have been a problem with backwards-compatibility as the original figure was created with MATLAB 5
==> as #Adrian and #Mikhail pointed out: it would be very very useful to use a Version control system in order to prevent to have hundreds of files with different numbers where most of them are of no use anymore
There seems to be some incompatibilities between different platforms and also between different versions, from my experience (MATLAB 5, 6, and 7) also -- I've encountered similar situations many times.
I am not exactly sure when the GUIDE became available with MATLAB -- I first noticed about it when I was using the first version of MATLAB 7. (It used to be very unstable at first, but is very usable now. For example, I vaguely remember a critical issue with MATLAB 7 Student version. You had to download a patch to make the GUIs work.)
Does your boss know how the *.fig file was created and in which MATLAB version? Can you open the *.fig on the old version of MATLAB and display the GUI correctly?
Some functions have possibly become obsolete since the earlier version of MATLAB that was used to create the figure, and may be causing some minor problem with it. If that is the case, you can troubleshoot it by checking all the error and warning messages that appear on the Command Window (or the MATLAB Console.)
Also, you should be able to load the *.fig files on the workplace using the following command from the Command Window, assuming that the files are in MATLAB's search path.
load your_file.fig -mat
You should then see a structure dataset, and see all of the figure properties, etc. in that structure.
You can use the information to create a new figure without the GUIDE (GUI Development Environment / Tool).
I recommend you writing your own GUI app. It's not that difficult, with/without the GUIDE.
I recently opened a site with some Tips on MATLAB Programming for beginners and intermediate users, and update it in my spare time. If you have any specific question about GUI building, I may (or may not) be able to provide answers there...
This is related somewhat to this question about a better shell terminal/gui-interface for cmd.exe
In my quest to find a better shell terminal, the only useful thing I came across was Console2, other alternatives weren't free and generally didn't offer much more than Console2 to make them worth their price.
I can't help but wonder, "how come"? The shell terminal is a very valuable tool to a programmer, yet no one came around to try and do a better job than cmd.exe (except for the guys # console2)??
Surely designing a command line shell terminal emulator can't be such a hard task!
Has anyone tried writing a shell terminal emulator before? What's in it? Any resources out there (say, if I want to program my own shell)?
UPDATE
17/07/2009
I rephrased the question, what I was referring to as a "shell" is actually called a terminal emulator (at least in the linux world). I only realized this recently so I thought I should revisit this question and fix it.
There are plenty of shells around for Windows, bash under Cygwin is the one I use the most, and it's certainly free. I have to be honest here, cmd.exe has come a long way since the batch file processor of MSDOS. It's actually quite powerful, but still not a pimple on the rear end of bash :-).
You should try to write a command line shell, it will be an education for you. It's not that hard to do the basics if all you want is a program launcher.
But, if you want all the power of a real shell, including a full blown programming language, job control, piping, output redirection and (seriously) too many other things to list, we probably won't be hearing from you for a while. Except when you pop up your head to ask us esoteric questions about how shells should do this or that.
What about PowerShell from Microsoft? AFAIK it's free, and gives you C# power right in the shell, and tons of other features. But, it DOES require the NET Framework...
I won't endorse it yet, as I haven't really used it, but it's on my list to do...
My bets are on Powershell for the future if you are a Windows guy.
PowerShell will be installed by default on Windows Server 08 R2 (WS08R2) and Windows 7 according to MS.
I have used Powershell myself and found it to be very useful, and if you are familiar with .NET then its all the more easier.
Download a two page reference document here, this is all you will need to get started.
I mean the gui-interface part that displays the text,
Ah! you mean what we call a "pseudo-tty" or a "terminal emulator" in unix. In windows, I guess it is called a "console host". I do not use windows, but I heard that console2 is very good.
Seems there are others:
http://www.powershellanalyzer.com/
http://powershellide.com/
http://www.codeplex.com/PoshConsole
and, of course, for real programmers, you have the shell mode of (x)emacs :-)
Erm... what about all the ports of Unix command shells to Windows?
Just go with cygwin and log on using PuTTY. So much better than the standard console. :)
Also, Python (or perl for that matter) can replace the shell entirely.
You might want to try Take Command Console, formerly 4NT, formerly 4DOS.
Quick summary of points you might care about:
Command line editing with filename completion, history, and cut & paste
Integrate PERL, Ruby, REXX, Python, and any Active Scripting language
Fast - 20-200% faster output display than the standard Windows console
Integrated file explorer - examine directories, drag and drop files
Upwardly compatible with CMD.EXE with literally thousands of additions
Not free (except trial version) and not open source. I haven't tried it myself, but I was a 4DOS junkie back in the day, before Cygwin.
If you need handy terminal - give a try to ConEmu (I'm the author). It is a Windows console window enhancement (local terminal emulator), which presents multiple consoles and simple GUI applications as one customizable tabbed GUI window with dozens of features.
Another answer and comments