PyCharm terminal freezes (or loops) when executing the file and the computer starts to warm up.
Code that doesn't run:
import time
import requests
start_time = time.time()
print(start_time)
Code that works:
Code that doesn't run:
import time
# import requests
start_time = time.time()
print(start_time)
The problem occurs when some libraries are present, for example requests, pycoingecko, pymongo. I assume that these are the libraries that access the Internet.
The problem occurred unexpectedly, the settings in the program did not change.
Everything worked before.
System: Ubuntu.
Related
I'm trying to host a music bot on repl.it and lavalink keeps terminating on. How do I stop it from terminating.
I had this problem for a few weeks. The solution is very simple.
import os
import time
import threading
def run_lavalink():
os.system("java -jar Lavalink.jar")
threading.Thread(target=run_lavalink).start()
time.sleep(20) #wait until lavalink is ready up
#bot.run and other stuffs
I've tried to run this code:
from time import clock
def f2():
t1 = clock()
res = ' ' * 10**6
print('f2:', clock()-t1)
but got Traceback:
from time import clock
ImportError: cannot import name 'clock' from 'time' (unknown location)
Python doesn't see the time module in the standard library?
I tried to install this module manually via pip (Yes, I know that it should already be installed. But what else could I do?). I got the following error in response:
ERROR: Could not find a version that satisfies the requirement time
ERROR: No matching distribution found for time
Trying to install the module via PyCharm also failed - it just runs pip and gets the same error.
I found the answer.
Method clock() in module time was deprecated in 3.8, see issue 36895.
So i used time.time()
import time
def f2():
t1 = time.time()
res = ' ' * 10**8
t2 = time.time()
print('f2:', t2 - t1)
Strange, but while googling the problem, I noticed that many people in 2019-2021 (after clock() deprecated in Python 3.8) had this error, but no one wrote how to solve it.
So my answer might be really helpful.
I'm new to Julia and, after a suggestion, I started using nightly build 1.6.0-DEV.1371 due to the high loading time of packages in Julia 1.5.2.
So I tried to change the default directory of DEPOT_PATH and copied all files from ~/.julia to /opt/julia (owned by my user). Now, if I start Julia using the default directory and run the code below, it takes about 4 seconds. However, when I start julia in the new directory (JULIA_DEPOT_PATH=/opt/julia julia), the same code takes incredible 83 seconds. The same happens with Julia 1.5.2 (17s in the default directory, 200s in the new directory).
This is the code I'm using to measure the time.
t = time(); using Plots; time() - t
Is there some explanation about this strange (and annoying) behavior?
My Platform Info:
Platform Info:
OS: Linux (x86_64-pc-linux-gnu)
CPU: Intel(R) Core(TM) i3-6100U CPU # 2.30GHz
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-9.0.1 (ORCJIT, skylake)
And I'm using a SSD.
There is a good chance that now you are having files from your previous Julia installation with the new Julia's JULIA_DEPOT_PATH. The normal approach is to set JULIA_DEPOT_PATH to an empty folder and then install them there.
Regarding startup times there are the following things you can do:
Precompile package (this is also happening when you use a new version of the package for the first time)
using Pkg
pkg"precompile"
Once Plots is precompiled it still takes around 10s to load each time.
If the above time is unacceptable build-in your Plots into Julia system image.
using PackageCompiler
create_sysimage(:Plots, sysimage_path="sys_plots.so", precompile_execution_file="precompile_plots.jl")
For the precompile_plots.jl you could use commands that you use regularly or perhaps test sets from Plots.jl.
Once done you will be starting Julia with the following comand:
julia --sysimage sys_plots.so
Building the system image takes long, however once done, loading Plots.jl will be a matter of milliseconds.
More information can be found here:
package compiler tutorial https://julialang.github.io/PackageCompiler.jl/dev/examples/plots/
excellent tutorial video https://live.juliacon.org/talk/Z8TE39
I don't know if someone else is running into this problem. I have this main.go file:
package main
import "fmt"
func main() {
fmt.Println("hello world")
}
when I run go build, it takes 5 secs to run it (regardless if it is the first time I run it or if it is the second time)
PS> Measure-Command {Start-Process go build -wait}
Days : 0
Hours : 0
Minutes : 0
Seconds : 5
Milliseconds : 151
Ticks : 51514117
TotalDays : 5.96228206018519E-05
TotalHours : 0.00143094769444444
TotalMinutes : 0.0858568616666667
TotalSeconds : 5.1514117
TotalMilliseconds : 5151.4117
But when I run it on a linux machine:
time go build
real 0m2.017s
user 0m0.054s
sys 0m1.915s
and when I run it for the second time:
time go build
real 0m0.120s
user 0m0.072s
sys 0m0.088s
This is not only build, but also some of go tools such as fmt. It takes 0.12 seconds on linux, but almost 3 seconds on windows. Other tools like guru, gocode, etc. suffer the same problem, making code development very slow.
I'm using golang 1.11. I'm using an SSD and everything is running locally. Sorry I wish I could be more helpful but I really have no idea where to start to debug this.
Does anyone has an idea what's going on?
It seems that the build cache is disabled on your Windows and enabled on your Linux.
Go build keeps the result of compilations and reuse it if the .go file hasn't changed. That's why your second build is so fast in Linux.
If you disable it, not only your code, but also all the dependancies must be recompiled each time. Thus even if you change your code, all the libs (here "fmt") are already in cache.
To test it, run go clean -cache before the go build on Linux, and see if the time correspond to the time on your Windows. Then if it matches, you have to find why the build cache is disabled on Windows.
You can see the cache directory by typing go env GOCACHE. If the response is off, the cache is off. Otherwise verify that the repository exists and it has the right permissions.
You can choos the cache directory by setting the value of the GOCACHE environment variable (sorry I don't know how to do this in Windows).
I was having same issue. Turns out I had a really big directory with 1000s of large files in the same location where the binary was. Moving the big dir out to a different location resolved the issue. This was in a macOS.
I'm trying to build my application into an .app file and I kept hitting the following error.
[Errno 2] No such file or directory: '/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl'
So I downloaded ActiveTcl8.5 and the error went away. Now I'm able to build using the following command:
python3 setup_cx_freeze.py bdist_dmg
But my application runs and immediately closes. I ran it from the cmd to get a sense as to what the error is and the only feedback I'm getting is LSOpenURLsWithRole() failed with error -10810. What am I doing wrong? Why did I need Tcl in order to use cx freeze and why does my app not want to open? This is my setup file.
import sys
from cx_Freeze import setup, Executable
build_exe_options = {"packages": ['tkinter', 'smb.SMBConnection'], "excludes": [], "includes": [], "include_files":['Project_Images', 'Project_Docs'], "bin_path_excludes": []}
setup(
name = "Test",
version = "2.51",
description = "Will this even work?",
options = {"build_exe": build_exe_options},
executables = [Executable("AccuAdmin.py")])
Tcl is a programming language, invented at roughly the same time as Python. Tkinter is a thin wrapper on top of an embedded tcl interpreter with the "tk" widget extension. You cannot use tkinter without tcl/tk.