Spyder 5.3.3 on Redhat8, Anaconda3, crashes while loading environment variables:
...
File "/home/user/anaconda3/envs/p311/lib/python3.11/site-packages/spyder/plugins/pythonpath/utils.py", line 31, in get_system_pythonpath
env = get_user_env()
^^^^^^^^^^^^^^
File "/home/user/anaconda3/envs/p311/lib/python3.11/site-packages/spyder/utils/environ.py", line 71, in get_user_env
env_dict = get_user_environment_variables()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/user/anaconda3/envs/p311/lib/python3.11/site-packages/spyder/utils/environ.py", line 63, in get_user_environment_variables
k, v = kv.split('=', 1)
^^^^
ValueError: not enough values to unpack (expected 2, got 1)
As a workaround, if I downgrade to an older spyder-kernels=2.3.3, then the environment variables are handled correctly. But spyder-kernels=2.4.1 create the error, which crashes the startup.
Tried to install a startup.py file to load the environment:
import os
os.environ['test']='test value'
hoping that it was an empty set that was causing the problem. No effect.
Looks like a clumsy implementation for reading the environment variables in the function get_user_environment_variables(), which will fail on environment variable values with newline characters in there.
Same problem here.
Edit the file (in your case) /home/user/anaconda3/envs/p311/lib/python3.11/site-packages/spyder/utils/environ.py
and change the get_user_environment_variables() function to read:
def get_user_environment_variables():
"""
Get user environment variables from a subprocess.
Returns
-------
env_var : dict
Key-value pairs of environment variables.
"""
return dict(os.environ.items())
Or wait until this Spyder bug is fixed.
Related
I am reading a few tutorials on Lua and am trying to figure out how to use unpack(). I found an example that goes like this:
t = { "the", "quick", "brown" }
print (unpack (t))
The output should be "the quick brown".
What actually happens is this: "stdin:1: attempt to call a nil value (global 'unpack')".
How can I make unpack() work?
My Info:
OS: Mac OS 10.8
Lua: 5.4.2
Since Lua 5.2 unpack function is now at table.unpack
Function unpack was moved into the table library and therefore must be called as table.unpack.
I have a problem with electron-builder since upgrading to Electron 10.1.2. My build now fails at rebuild for keyboard-layout. The rebuild only fails for Windows, not Mac. I don't know where to open this issue so I am asking here :).
My setup:
angular: 9.0.7
electron: 10.1.2
electron-builder: 22.8.x
The problem started when I updated electron from 9.0.0 to 10.1.2. Nothing else changed.
The problem:
When calling electron-builder with command electron-builder.cmd --x64 -p always -w rebuild of keyboard-layout is called as one of the steps as:
> keyboard-layout#2.0.16 install C:\Users\<me>\<dir1>\<dir2>\dist\node_modules\keyboard-layout
> node-gyp rebuild
That fails with:
...
win_delay_load_hook.cc
c:\users\<me>\.electron-gyp\10.1.2\include\node\v8.h(5378): error C2220: warning treated as error - no 'object' file generated (compiling source file ..\src\keyboard-layout-manager-windows.cc) [C:\Users\<me>\<dir1>\<dir2>\dist\node_modules\keyboard-layout\build\keyboard-layout-manager.vcxproj]
c:\users\<me>\.electron-gyp\10.1.2\include\node\v8.h(5378): warning C4309: 'static_cast': truncation of constant value (compiling source file ..\src\keyboard-layout-manager-windows.cc) [C:\Users\<me>\<dir1>\<dir2>\dist\node_modules\keyboard-layout\build\keyboard-layout-manager.vcxproj]
c:\users\<me>\.electron-gyp\10.1.2\include\node\v8.h(5378): error C2220: warning treated as error - no 'object' file generated (compiling source file ..\src\keyboard-layout-manager.cc) [C:\Users\<me>\<dir1>\<dir2>\dist\node_modules\keyboard-layout\build\keyboard-layout-manager.vcxproj]
c:\users\<me>\.electron-gyp\10.1.2\include\node\v8.h(5378): warning C4309: 'static_cast': truncation of constant value (compiling source file ..\src\keyboard-layout-manager.cc) [C:\Users\<me>\<dir1>\<dir2>\dist\node_modules\keyboard-layout\build\keyboard-layout-manager.vcxproj]
Done Building Project "C:\Users\<me>\<dir1>\<dir2>\dist\node_modules\keyboard-layout\build\keyboard-layout-manager.vcxproj" (default targets) -- FAILED.
Done Building Project "C:\Users\<me>\<dir1>\<dir2>\dist\node_modules\keyboard-layout\build\binding.sln" (default targets) -- FAILED.
Build FAILED.
...
What I have tried that DID NOT help:
Change binding.gyp in node_modules/keyboard-layout to (chnages marked with <---):
['OS=="win"', {
"sources": [
"src/keyboard-layout-manager-windows.cc",
],
'msvs_settings': {
'VCCLCompilerTool': {
'ExceptionHandling': 1, # /EHsc
'WarnAsError': 'false', # <--- I chnaged this from true to false
},
},
'msvs_disabled_warnings': [
4018, # signed/unsigned mismatch
2220, # <--- I added this
4244, # conversion from 'type1' to 'type2', possible loss of data
4267, # conversion from 'size_t' to 'type', possible loss of data
4302, # 'type cast': truncation from 'HKL' to 'UINT'
4311, # 'type cast': pointer truncation from 'HKL' to 'UINT'
4530, # C++ exception handler used, but unwind semantics are not enabled
4506, # no definition for inline function
4577, # 'noexcept' used with no exception handling mode specified
4996, # function was declared deprecated
],
}], # OS=="win"
What I have tried that DID help:
Electron 10.x.y updated v8 to 8.5 (Electron 10.0.0 release notes) and looking at line that causes the error (...\.electron-gyp\10.1.2\include\node\v8.h(5378)) I see this:
static constexpr size_t kMaxLength =
internal::kApiSystemPointerSize == 4
? internal::kSmiMaxValue
: static_cast<size_t>(uint64_t{1} << 32); <--- Line 5378
When I compare v8.h files from ...\.electron-gyp\10.1.2\include\node\v8.h and ...\.electron-gyp\9.0.0\include\node\v8.h, there is a change in this exact line.
Same line in old version:
static constexpr size_t kMaxLength = internal::kApiSystemPointerSize == 4
? internal::kSmiMaxValue
: 0xFFFFFFFF;
If I chnage static_cast<size_t>(uint64_t{1} << 32) to 0xFFFFFFFF, build succeedes.
My understanding ends here.
Are the old and new lines not theoretically the same? One shifted for 32 bits results in 0xFFFFFFFF?
What can I do to fix this issue and what could be the reason for this change?
Why is this problem only on Windows?
What I have tried that DID NOT help:
'WarnAsError': 'false' should do the trick; however the error was reported for two different files (..\src\keyboard-layout-manager.cc and ..\src\keyboard-layout-manager-windows.cc) so you'd have to modify the build rules for both of them.
Disabling the warning should help too, but it'd have to be warning 4309 (not 2220) that you need to disable. Again, you'd have to do that for both files (or just for the entire compilation).
Are the old and new lines not theoretically the same? One shifted for 32 bits results in 0xFFFFFFFF?
No, 1 << 32 == 0x100000000 == 0xFFFFFFFF + 1).
What can I do to fix this issue?
turning off 'WarnAsError' should help
turning off warning 4309 should help
reverting that one line in your local checkout should help
using Clang instead of MSVC should help
possibly using a different (newer?) version of MSVC would also help
and what could be the reason for this change?
V8 now allows TypedArrays with up to 2**32 elements, which is one more element than before.
Why is this problem only on Windows?
Because warnings are compiler-specific, and MSVC is only used on Windows.
The weird part is that you're seeing this error in the first place. You compile with --x64; if that does what it sounds like, you should be compiling a 64-bit build, where internal::kApiSystemPointerSize == 8 and size_t has 64 bits just like uint64_t, so in the expression static_cast<size_t>(uint64_t{1} << 32); nothing gets truncated.
Even if for whatever reason this build tried to create a 32-bit build of V8, then the other branch should be taken (internal::kApiSystemPointerSize == 4) and the compiler should be smart enough not to warn about a branch that's statically dead anyway.
At any rate, this seems like a compiler bug/limitation. So appropriate workarounds are to either update your compiler, or disable the erroneous warning.
A PicklingError is raised when I run my data pipeline remotely: the data pipeline has been written using the Beam SDK for Python and I am running it on top of Google Cloud Dataflow. The pipeline works fine when I run it locally.
The following code generates the PicklingError: this ought to reproduce the problem
import apache_beam as beam
from apache_beam.transforms import pvalue
from apache_beam.io.fileio import _CompressionType
from apache_beam.utils.options import PipelineOptions
from apache_beam.utils.options import GoogleCloudOptions
from apache_beam.utils.options import SetupOptions
from apache_beam.utils.options import StandardOptions
if __name__ == "__main__":
pipeline_options = PipelineOptions()
pipeline_options.view_as(StandardOptions).runner = 'BlockingDataflowPipelineRunner'
pipeline_options.view_as(SetupOptions).save_main_session = True
google_cloud_options = pipeline_options.view_as(GoogleCloudOptions)
google_cloud_options.project = "project-name"
google_cloud_options.job_name = "job-name"
google_cloud_options.staging_location = 'gs://path/to/bucket/staging'
google_cloud_options.temp_location = 'gs://path/to/bucket/temp'
p = beam.Pipeline(options=pipeline_options)
p.run()
Below is a sample from the beginning and the end of the Traceback:
WARNING: Could not acquire lock C:\Users\ghousains\AppData\Roaming\gcloud\credentials.lock in 0 seconds
WARNING: The credentials file (C:\Users\ghousains\AppData\Roaming\gcloud\credentials) is not writable. Opening in read-only mode. Any refreshed credentials will only be valid for this run.
Traceback (most recent call last):
File "formatter_debug.py", line 133, in <module>
p.run()
File "C:\Miniconda3\envs\beam\lib\site-packages\apache_beam\pipeline.py", line 159, in run
return self.runner.run(self)
....
....
....
File "C:\Miniconda3\envs\beam\lib\sitepackages\apache_beam\runners\dataflow_runner.py", line 172, in run
self.dataflow_client.create_job(self.job))
StockPickler.save_global(pickler, obj)
File "C:\Miniconda3\envs\beam\lib\pickle.py", line 754, in save_global (obj, module, name))
pickle.PicklingError: Can't pickle <class 'apache_beam.internal.clients.dataflow.dataflow_v1b3_messages.TypeValueValuesEnum'>: it's not found as apache_beam.internal.clients.dataflow.dataflow_v1b3_messages.TypeValueValuesEnum
I've found that your error gets raised when a Pipeline object is included in the context that gets pickled and sent to the cloud:
pickle.PicklingError: Can't pickle <class 'apache_beam.internal.clients.dataflow.dataflow_v1b3_messages.TypeValueValuesEnum'>: it's not found as apache_beam.internal.clients.dataflow.dataflow_v1b3_messages.TypeValueValuesEnum
Naturally, you might ask:
What's making the Pipeline object unpickleable when it's sent to the cloud, since normally it's pickleable?
If this were really the problem, then wouldn't I get this error all the time - isn't a Pipeline object normally included in the context sent to the cloud?
If the Pipeline object isn't normally included in the context sent to the cloud, then why is a Pipeline object being included in my case?
(1)
When you call p.run() on a Pipeline with cloud=True, one of the first things that happens is that p.runner.job=apiclient.Job(pipeline.options) is set in apache_beam.runners.dataflow_runner.DataflowPipelineRunner.run.
Without this attribute set, the Pipeline is pickleable. But once this is set, the Pipeline is no longer pickleable, since p.runner.job.proto._Message__tags[17] is a TypeValueValuesEnum, which is defined as a nested class in apache_beam.internal.clients.dataflow.dataflow_v1b3_messages. AFAIK nested classes cannot be pickled (even by dill - see How can I pickle a nested class in python?).
(2)-(3)
Counterintuitively, a Pipeline object is normally not included in the context sent to the cloud. When you call p.run() on a Pipeline with cloud=True, only the following objects are pickled (and note that the pickling happens after p.runner.job gets set):
If save_main_session=True, then all global objects in the module designated __main__ are pickled. (__main__ is the script that you ran from the command line).
Each transform defined in the pipeline is individually pickled
In your case, you encountered #1, which is why your solution worked. I actually encountered #2 where I defined a beam.Map lambda function as a method of a composite PTransform. (When composite transforms are applied, the pipeline gets added as an attribute of the transform...) My solution was to define those lambda functions in the module instead.
A longer-term solution would be for us to fix this in the Apache Beam project. TBD!
This should be fixed in the google-dataflow 0.4.4 sdk release with https://github.com/apache/incubator-beam/pull/1485
I resolved this problem by encapsulating the body of the main within a run() method and invoking run().
I am a newbie to Lua. Currently getting the following error message:
invalid argument type for argument -model (should be the model checkpoint
to use for sampling)
Usage: [options] <model>
I am sure it is something pretty easy to solve, but cannot manage to find the solution.
The 'model' is a file lm_checkpoint_epoch50.00_2.7196.t7, which is in the directory
/home/ubuntu/xxx/nn/cv
I am running the program from the parent directory (/home/ubuntu/xxx/nn)
I have tried out the following options to run the program (from one directory above the one the model is saved):
th sample.lua - model lm_chelm_checkpoint_epoch50.00_2.5344.t7
th sample.lua lm_chelm_checkpoint_epoch50.00_2.5344.t7
th sample.lua /cv/lm_chelm_checkpoint_epoch50.00_2.5344.t7
th sample.lua - /cv/model lm_chelm_checkpoint_epoch50.00_2.5344.t7
Also, the program has a torch.CmdLine() object where :argument equals '/cv/lm_checkpoint_epoch50.00_2.7196.t7'. The program prints the parameters, so that you see the following output on the screen:
Options
<model> /cv/lm_checkpoint_epoch50.00_2.7196.t7
so it finds a value for argument 'model', which is picked up from the .lua file, not the parameter in the command line. This file is a valid mode.
Pretty lost, hope someone relates to this issue. Thanks.
found the issue - it was a bug as smhx suggested. I inadvertently changed the source code from:
require 'torch'
cmd = torch.CmdLine()
cmd:argument('-model','model checkpoint to use for sampling')
Note that there is no argument in the source code. To:
cmd:argument('-model','/cv/model lm_chelm_checkpoint_epoch50.00_2.5344.t7'
'model checkpoint to use for sampling')
So the argument must be passed through the command line, not the source code. With parameters, it is different - you can include them in the source code.
So if I change back the source code and run the following from the command line:
th sample.lua cv/lm_chelm_checkpoint_epoch50.00_2.5344.t7
it works.
I just installed macvim yesterday and I installed vim latex today.
One of the menu items is calling a broken function (TeX-Suite -> view).
When I click on the menu-time it makes this call:
:silent! call Tex_ViewLatex()
Question: Where can I find that function? Is there some way to figure out where it is defined?
Just for curiosity sake I removed the silent part and ran this:
:call Tex_ViewLatex()
Which produces:
Error detected while processing function Tex_ViewLaTeX:
line 34:
E121: Undefined variable: s:viewer
E116: Invalid arguments for function strlen(s:viewer)
E15: Invalid expression: strlen(s:viewer)
line 39:
E121: Undefined variable: appOpt
E15: Invalid expression: 'open '.appOpt.s:viewer.' $*.'.s:target
line 79:
E121: Undefined variable: execString
E116: Invalid arguments for function substitute(execString, '\V$*', mainfname, 'g'
)
E15: Invalid expression: substitute(execString, '\V$*', mainfname, 'g')
line 80:
E121: Undefined variable: execString
E116: Invalid arguments for function Tex_Debug
line 82:
E121: Undefined variable: execString
E15: Invalid expression: 'silent! !'.execString
Press ENTER or type command to continue
I suspect that if I could see the source function I could figure out what inputs are bad or what it is looking for.
Use the :verbose prefix command:
:verbose function Tex_ViewLaTeX
In the second line of output (just above the function's body) is the location of where the function was defined.
I installed gVim 7.2 on windows and latex-suite, and miktex too
I tried what you said, after compile and view, I can view the dvi files
The error message seemed like to indicate it's the view's problem
The document for latex-suite said the viewer for Macintosh is not set, maybe it's where the problem lies
I think you can try to set a few variables in your .vimrc file, to set up the proper viewing app for PDF files
And the source code for Tex_ViewLaTeX is here:
http://www.tedpavlic.com/research_related/tpavlic_masters_thesis/compiler.vim
By the way, I also installed MacVim on my Macbook Pro, however I never used vim for LaTeXing, because I find TextMate and its latex bundle is much superior than MacVim, you'll definately like it
One way to search would be to do a grep or vimgrep on directory tree where you thought the source file was located. Search for 'function Tex_ViewLatex' or 'function! Tex_ViewLatex'.
I believe in the usual install it would be in a .../ftplugin/latex-suite/compiler.vim file, as part of the latex-suite plugin. There are a couple ftplugin directories, so make sure you get right one (one is in tree of main vim install and other may be off your home .vim directory.
It seems there is a bug with the Tex_ViewLatex function on OS X. Check here for some info:
http://comments.gmane.org/gmane.comp.editors.vim.latex.devel/775
Put this in your .vimrc, solved the problem for me.
let g:Tex_ViewRule_pdf = 'open -a Preview.app'