I try to install my addon in Pale Moon but get this exception:
An exception occurred.
Error: Module `sdk/io/fs` is not found at resource://gre/modules/commonjs/sdk/io/fs.js
resource://gre/modules/commonjs/sdk/loader/cuddlefish.js 133
Traceback (most recent call last):
File "resource://gre/modules/NetUtil.jsm", line 137, in
aCallback(pipe.inputStream, aStatusCode, aRequest);
File "resource://gre/modules/commonjs/sdk/net/url.js", line 49, in readAsync/<
resolve(data);
...(long trace)
So what sdk i must use on pale moon to work with file system?
What version of Firefox is Palemoon based on? If it's very old you shuld try SDK 1.14:
https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/addon-sdk-1.14.zip
You should also look at the documentation for this version of the SDK ( run cfx docs ) as the current docs on will include modules that have been introduced more recently. sdk/io/fs, for example was only introduced last summer and shipped last fall.
Related
I have a Mac Mini M1 with BigSur os. I am trying to run a program that opens a window from Vulkan tutorial. I downloaded the latest version of Vulkan and folowed the Vulkan Tutorial how to set it up on XCode. I copied the files to a different location as sugested but when I got to the point to link the libraries I cannot find libvulkan.1.dylib in the location they specify and obviuosly I get an error when I run the program that the library is missing: dyld: Library not loaded: #rpath/libvulkan.1.dylib.
I have seen that you can install it using sudo ./install_vulkan.py or simply ./install_vulkan.py from terminal but I am getting this error:
Copying /Users/username/VulkanSDK/macOS/lib/cmake/SPVRemapperTargets.cmake to /usr/local/lib/cmake/vulkan
Traceback (most recent call last):
File "./install_vulkan.py", line 141, in <module>
main()
File "./install_vulkan.py", line 120, in main
os.mkdir(os.path.split(absolute_copy_files[key]["Dest"])[0])
OSError: [Errno 2] No such file or directory: '/usr/local/lib/cmake'`.
I have looked for /usr/local/lib/cmake path but there is no /lib inside the /usr/local/.
I understand that in BigSur the paths are changed and I have seen where the packages are installed via Homebrew. I looks like the new default path is /opt/Homebrew if I am not mistaken. The problem I think is that ./install_vulkan.py doesn't know about these changes from MacOS BigSur.
Does anyone have similar issues with the paths in the new MacOS?
We changed the documentation staring in the 1.2.162.0 release of the VulkanSDK to explicitly state you should use sudo when running ./install_vulkan.py. This is necessary because the program needs to create the needed folders. Technically, you can get away without sudo if you've installed and are using homebrew, which also creates these folders.
Regarding the missing vulkan.1.dylib, this is a mystery from my end. It is a symbolic link to the actual library, so perhaps something has gone awry when extracting the .dmg file or copying the contents out. You can also specifically link directly to the library itself instead (libvulkan1.2.162.dylib if you are using the latest SDK) and not use the symbolic link at all.
I'm trying to setup my first development for esp32 with eclipse on windows 7.
I installed esp-idf using esp-idf-tools-setup.exe installer which should install
everything needed.
I'm testing with the hello world example app from esp-idf. I can compile it using the python command line
idf.py build
But I need eclipse, it's a bit less obvious... I followed these instructions:
In this page, I can see that there's a need of msys. So I installed
msys2 64 bits.
I copied the xtensa-esp32-elf dir into the "msys64\var\opt" directory to match the PATH variable (and updated it based on the documentation)
Now, when compiling with eclipse, I got the following error:
Traceback (most recent call last):
File "C:/program/esp-idf/tools/windows/eclipse_make.py", line 36, in <module>
main()
File "C:/program/esp-idf/tools/windows/eclipse_make.py", line 29, in main
make = subprocess.Popen(["make"] + sys.argv[1:] + ["BATCH_BUILD=1"], stdout=subprocess.PIPE)
File "C:\python27\lib\subprocess.py", line 390, in __init__
errread, errwrite)
File "C:\python27\lib\subprocess.py", line 640, in _execute_child
startupinfo)
WindowsError: [Error 2] Le fichier spécifié est introuvable
Python make is unable to launch "make". The thing is I can't find a make exe anywhere...
This other page states that I must run
make menuconfig
before building with eclipse but, of course, this does not work better for the same reason...
What should I do?
Well, in windows you have nmake (IIRC installed with visual studio tools - or the free where vstools compiler pack). Or you can install something more like gnu-make from one of:
mingw32 : link
cygwin : link
msys2 : link
gnuwin32 : link
There are others as well. Some of these have make command (if you add the bin folder to your path) others will have things like mingw32-make which you may have to alias (I made a batch file called make.bat which just calls mingw32-make %*. But where ever you install make (and nmake IMHO is a really limited poor version of make) you need to add it to your windows path before you run your python script. So in short I think you are just missing a set of tools...
Another option is to just copy ...\MinGW\bin\mingw32-make.exe to ...\MinGW\bin\make.exe
I did add mys2 thinking it will contain everything needed.
In fact msys2 is delivered with a very minimal set of features. I had to install make using the msys2 package manager with the following command:
pacman -S make
Pretty simple when you know!
For esp-idf cmake projects, try this https://github.com/espressif/idf-eclipse-plugin
I followed instructions in the below link to set up google assistant in my Windows PC.
https://developers.google.com/assistant/sdk/guides/library/python/
But in the step while running the hotword command, i am getting the below error :
Traceback (most recent call last):
File "c:\users\310211247\appdata\local\continuum\miniconda3\lib\runpy.py",line 193, in
_run_module_as_main
"__main__", mod_spec)
File "c:\users\310211247\appdata\local\continuum\miniconda3\lib\runpy.py", line 85, in _run_code
exec(code, run_globals)
File "C:\Users\310211247\AppData\Local\Continuum\miniconda3\Scripts\googlesamples-assistant-hotword.exe\__main__.py", line 5, in <module>
File "c:\users\310211247\appdata\local\continuum\miniconda3\lib\site-packages\googlesamples\assistant\library\hotword.py", line 27, in <module> from google.assistant.library import Assistant
ModuleNotFoundError: No module named 'google.assistant.library'
How can i resolve this error?
As noted in the Compatibility section for the library, it is only supported on linux-armv7l and linux-x86_64 architectures. The library is not expected to work on a Windows device. Instead, you should look at using the service API.
Google's recommendation is to use the assistant service:
The Google Assistant Library for Python is deprecated as of June 28th, 2019
You can configure the assistant following these instructions:
https://developers.google.com/assistant/sdk/guides/service/python/
After installation to get the hotword working you need to install the assistant library:
pip install google-assistant-library
Then you can run the google assistant with the hotword:
googlesamples-assistant-hotword --project-id project --device-model-id model
I currently have a Hyper-V Virtual machine whose guest OS is Microsoft Server 2016
I was able to install the Docker Service and use the command line to create a docker image
I would like to try the same process out in Visual Studio using compose, but it looks like that will only work if the ToolBox is installed. I installed the Toolbox and when I build I get an error around the volume spec, I believe this is because the target OS is Linux.
Since Windows Server 2016 is not compatible with Docker for Windows, is it the case that when targeting Windows Containers onc can only use the service + powerhsell, and if they want to use Compose in Visual Studio I would have to disable the hyper-visor internally and make sure the Linux VM is running?
I am a little confused on the workflow regarding windows server + VS with Docker. Thanks for any clarification.
EDIT:
I uninstalled the ToolBox to simplify the environment, I downloaded compose this way:
Invoke-WebRequest " https://github.com/docker/compose/releases/download/1.15.0-rc1/docker-compose-Windows-x86_64.exe" -UseBasicParsing -OutFile $Env:ProgramFiles\docker\docker-compose.exe
And now the build error is:
ERROR: for dockercompose1517717654_azurecontainersite_1 __init__() got an
unexpected keyword argument 'cpu_count'
ERROR: for azurecontainersite __init__() got an unexpected keyword
argument 'cpu_count'
Traceback (most recent call last):
File "docker-compose", line 3, in <module>
File "compose\cli\main.py", line 68, in main
File "compose\cli\main.py", line 118, in perform_command
File "compose\cli\main.py", line 926, in up
File "compose\project.py", line 424, in up
File "compose\parallel.py", line 69, in parallel_execute
TypeError: __init__() got an unexpected keyword argument 'cpu_count'
Failed to execute script docker-compose.
At this time Visual Studio tools only support Linux Containers. If/when that changes I will update this answer.
Also to get VS with Compose to work on Server 2016, I installed the edge version of Docker for Windows with the following link:
https://store.docker.com/editions/community/docker-ce-desktop-windows
I tried running lldb on my mac and get this at startup:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/System/Library/PrivateFrameworks/LLDB.framework/Versions/A/Resources/Python/lldb/embedded_interpreter.py", line 1, in <module>
import readline
ImportError: /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/readline.so: no appropriate 64-bit architecture (see "man python" for running in 32-bit mode)
Traceback (most recent call last):
File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
I tried adding the environment variable VERSIONER_PYTHON_PREFER_32_BIT=yes but this error still appears. I'd reckon that the lldb is using a different python environment than it's Mac host so where do I make the change to make it use 32bit mode? thanks.
UPDATE:
I did an arch -i386 lldb and it works in 32-bit. To make it work in 64-bit, I installed a 64-bit version of python readline for OS X but got more problems with native python libraries such as termios and time. So I downloaded python 2.7.3 64-bit installer DMG file and installed its binary; now lldb works in 64 bit finally on my 10.8 mountain lion. Thanks.
It looks like you installed /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/readline.so at some point on your system (I don't see it on my Mac OS X 10.7.5 installation, although maybe it's included in 10.8), and that dylib is only built 32-bit. You can confirm with
file /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/readline.so
on your system. You could try to force lldb to also run in 32-bit mode (the distribution binary is built 32-/64- universal) but instead I would recommend removing that 32-bit-only readline.so from your system unless you really need it there.
For the sake of anyone else coming to this question looking for a quick fix - Linus Oleander's answer worked for me -- that is, run
pip install six
Hazarding a guess as to why this works, I think this smooths over some python incompatibility issues that lldb is facing when running on machines with a 'non-standard' python installation. This also works when using Homebrew's version of llvm.