Pycharm - Waiting for REPL response when python console using IPython - python-3.x

Response times in a PyCharm Python Console are unbearably slow when the console is configured to use IPython. This wasn't the case in a previous installation. When the Python Console is not configured to use IPython, and uses IDLE, it performs normally.
The poor response time seems to be linked to the REPL response function, as depicted in the image below. When the REPL response dialog completes, a background process continues to run for several minutes.
Since this was not a problem in a previous installation, the issue must be a result of a configuration change. However, the only thing I changed was to utilize a Conda env instead of a virtualenv.
Any ideas?

This issue was reported to JetBrains. The issue was duplicated and identified as a bug. The status of the issue can be viewed at:
https://youtrack.jetbrains.com/issue/PY-24880

Here is how to apply the "answer" found in the JetBrains bug filed by #vlmercado https://youtrack.jetbrains.com/issue/PY-24880:
Disable auto popup completions (in Editor->General->Code Completions)

Posting my comment as an answer, I have tried it now for a few days and had 0 REPL hangups.
Ubuntu but should work on every machine.
Go to: File----> Settings---->Editor---->General---->Code Completion
Uncheck Rank completion suggestions based on Machine Learning
That's it. Happy Coding.

Today I had the same problem in Pycharm2019.3 with Python3.8. It may have been caused by using miniconda instead of the full anaconda installation, because after installing the ipython package (with -conda install ipython) the long REPL waiting times have dissappeared.

I am not sure if it is solved by jetbrains, for me, it just randomly starts even after 1-2 hrs of coding,
I have tried every options found in Jet brains as well as Stack Overflow like checking and unchecking of 1,2 in combination as shown in image. Have experienced same with the code completion option as well,
These options might help:
Settings: File > Settings > Build, Execution, Deployment > Console
Ipython Setting option:
Run with Console option:

Related

VS Code input and variables don't show frequently in Interactive window

I have started using VS Code for work instead of Anaconda and there are some weird observations which I am not able to figure out.
If I try to execute some code in a cell in the interactive window, many-a-times, only output remains available and the input code automatically gets hidden. For eg. I type the following and execute:-
And this is what I see at the window:-
Similarly, there are some variables which I have already defined but they don't show up in the Jupyer:Variables tab. For eg. there is a variable _link_name_to_index which is not visible in the tab as shown below:-
However, when I execute the same in the window, I can see the values of the dictionary as expected:-
Maybe it is just a matter of some settings, but I still couldn't find out which one. Also, I know I have put a lot of images, because it is not a code doubt as such, rather more of a tool doubt. I have taken only one particular example here, but I face this issue often. I am using VS Code version 1.75.0 in Ubuntu 20.04, using Python 3.9.12 in a virtual environment, if it helps.
This is a bug in the latest Version of VSCode (1.75). It is tracked in this issue. For now, the only option seems to be downgrading to v1.74.x

Spyder 3.2.8: Code only adopts changes for the first time after that restart of Spyder/Kernel necessary

So originally i thought it only affected changes to my plots but no changes to my code are applied even after saving the *.py file.
After updating to Spyder 3.2.8 the problem still persists.
I found a workaround by restarting the kernel and then rerunning the code so i don't have to close and reopen spyder every time at least.
The problem with this solution is that all my variables are deleted ofc. I found a solution to my problem here
Spyder IDE reload code with run selection ('F9')
and here IPython 3.2.1 documentation.
But when i enter the the first command in ipthyon it tells me it's already activated and after that neither %autoreload nor %autoreload 2 seem to have an effect.
As an example for my problem you can basically take the code example at the IPython 3.2.1 documentation link. For me it wouldn't update from 42 to 43 but still stay at 42.
Another thing is it seems to adopt the first changes i do. I start Spyder run my code everything is fine. I then change something in a *.py file like changing the name of an axis label in a plot. If i run the whole code again or just the changed function with the IPython console it works and integrates the change accordingly. But after that no changes are updated anymore.

Python code terminated in Pycharm with exit code 1073741819

Python version: 3.4
Hi, I was running a small Python code in Pycharm, but it was terminated with the exit code 1073741819.
I've tried the same code in the Python command line and Anaconda, and both worked. Any idea why Pycharm has the problem, and how can I get it work in Pycharm? Thanks a lot.
Its too late to answer now, but maybe it helps someone else. My code also worked right with command line but not inside pycharm, it usually happens when we switch between different projects on PyCharm.
I fixed it by:
1- Restarting the Pycharm and reloading the project into it.
2- Clearing the heap memory by clicking at this in status bar:
and now it works pretty fine.
P.S: If this indicator doesnt appear then visibility of this section in the Status bar is defined by the Show memory indicator check box in the Appearance page of the Settings/Preferences dialog. It is not shown by default.

PyQt Release vs Debug

I have a system,written on PyQt4. It is mostly developed and debug under linux (ubuntu) systems, in Eric IDE, and everything works fine. Last task was to create a nested editor for a table cell. So, i did it and it also looks nice in ubuntu. I also ran it under Windows 7 x64, and the behavior was the same.
However, after making executable file with cx_Freeze in Windows 2000 (it's weird, but this environment was configured before me), the editors behavior became unexpected. After opening Editor it's first cell have 'role == Qt.EditRole', and it's almost impossible to commit any changes there without closing the whole Editor. Another issue is about "OK" button - it closes the Editor window, but doesn't commit any changes in it also, and you cannot call it again without changing the active cell (but maybe i just forgot to emit some signals here, so it's not the main bug here).
So my question - where should i look to find the reason for these problems. I'm new to qt, and maybe it is normal behavior and just my fault in code? Or the reason is in different environments (python 2.7, latest pyqt vs python 2.6 and some older pyqt). Or it is the influence of cx_Freeze... Maybe some other directions?
Sorry for long post and my English :)
Hope to get any answers soon.
I think there's a chance that Qt or PyQt on windows 2000 server is outdated or broken.
So If possible, bring cx_freeze related code to your local computer and test it out.
If it fixes the problem, you can upgrade or reinstall Qt on windows 2000 server.

Issue running firefox built from source (on Ubuntu 9.10)

The title of the question sums it up pretty well. I've downloaded the source for firefox 3.6 and built it (no errors), but when I try to run it, I get a warning that says:
(firefox-bin:2857): GLib-WARNING **: g_set_prgname() called multiple times
I'm not sure what to try now. Any suggestions? Or even a better place to ask this question?
*EDIT - It's not that I only get a warning, that wouldn't bother me. The problem is that the warning is the only thing that ever happens (no firefox windows show up or anything). When I run it from the terminal, that warning shows up twice and then nothing else happens (it just hangs and I have to Ctrl-C it).
Bug in Glib introduced while trying to fix https://bugzilla.gnome.org/show_bug.cgi?id=563627 and, as discussed in that bug, later backed out because of the issue you're seeing. The warning will go away once you get a newer version of Glib.
Quick comments:
It's a warning, not an error. This is not a problem but looks like the library wanted to be used differently. So why worry?
Why did you build it from source? If you want newer packages, I usuaully start with Debian sources and turn those into local packages -- as this incorporates whatever the package maintainers deemed worthy and will be closer to the package you will get at the next Ubuntu upgrade.

Resources