Answer to a similar question suggests that I cannot import Shell stuff in a standalone mode. However, as I understand it, St is a separate library written in C. Yet I still cannot import it in gjs...
I.e.
$ gjs -c "imports.gi.Gtk"
works (i.e. no output). But
$ gjs -c "imports.gi.St"
fails with
Error: Requiring St, version none: Typelib file for namespace 'St' (any version) not found
Is there any way to import St library from a standalone (not GNOME Shell extension) gjs?
Some of them are not there (e.g. Meta, Shell, St) because they are considered "private".
Read more here on how to import them:
http://mathematicalcoffee.blogspot.ca/2012/09/developing-gnome-shell-extensions_6.html?m=1
St Lib would really (!!!) help in writing apps with custom interfaces due to the use of CSS. If we could use the library with Clutter and gjs it would really attract developers due the easy of use of St and Shell libraries.
Related
I would like to migrate some python code to swift which includes numpy and found a library called Matft.
I'm doing this on a VM and Xcode is very slow, so it would be great to avoid that and use the terminal (ideally run the .swift from a shared folder), but than I got the error: "no such module".
I found that I could pass -I flag and specify a path for the lib, but does not working for me.
Can someone give an easy explanation how to import external library in such situation?
I recently started learning python I wanted to know if I can convert my python code(in pycharm) to some sort of application which can be run without the IDE on other computers.(somewhat like we can run Android application by converting them to APK and use them on phones)
One approach you can take is, use a framework like flask, Django, and host it.
Secondly, you can use pyinstaller to make your python script into a Windows, Mac and Linux executable
There may be multiple answers for this, but one answer would be to use Auto-Py-To-Exe to convert python code to executables, which can be ran standalone in Windows.
You can find it at https://pypi.org/project/auto-py-to-exe/.
USE Pyinstaller:
In Linux (Tested on Ubuntu):
pyinstaller --onefile filename.py
In default, pyinstaller loads all the modules which makes the file bigger in size.
To avoid this, you can exclude modules like this
pyinstaller --onefile --exclude matplotlib --exclude scipy --exclude pandas --exclude numpy filename.py
If pyinstaller misses your module, you can import like this
pyinstaller --onefile --hidden-import=module_name filename.py
I am adding some theorems to the library
https://github.com/coq-contribs/zfc
But there is a not very good thing.
While I developing the code in the CoqIDE I have to add
Add LoadPath "/home/user/0my/GITHUB/".
and to rename all
Require Import Axioms.
to
Require Import ZFC.Axioms.
. All files of the library are in
/home/user/0my/GITHUB/ZFC
and the name of the last folder matters.
But when I want to run the "make" command I have to rename everything back.
The file "Make" contains the names of files and the prefix. Deleting the first line didn't solve the problem.
I don't think that it is the best practice of the developing with the CoqIDE, so what shall I do instead?
Edited1:
I have "run_coqide.sh" which consist of
#!/usr/bin/env bash
COQPATH=/home/user/0my/GITHUB/
/home/user/opam-coq.8.8.1/4.02.3/bin/coqide
"From ZFC Require Import Sets. " raises error "Cannot find a physical path".
Edited2:
I have find out that this is a working script:
#!/usr/bin/env bash
export COQPATH=/home/user/0my/GITHUB/
/home/user/opam-coq.8.8.1/4.02.3/bin/coqide
Is it normal run or a hack?
Rename Make to _CoqProject, this is the name currently recognized by CoqIDE where it will look for project configuration (in particular the -R . ZFC option to make the Coq files in the directory visible to CoqIDE).
It is also possible to change the name CoqIDE is looking for to Make, but _CoqProject seems to really be the new standard.
Note that the -R . ZFC option, that allows you to import libraries unqualified, corresponds to the command Add Rec LoadPath "/.../ZFC" as ZFC.
I would also suggest to actually switch the whole codebase to explicit qualification ZFC.Axiom, that you've been doing locally by hand, making it less error prone to work with different projects at the same time. I'm not sure why it was necessary to rename things back to run make, my understanding is that it shouldn't be necessary.
See also the Coq reference manual, about the coq_makefile utility.
I have a little benchmark suite, which compares different approaches to writing and executing some simple toy Python code, mainly for the purpose of illustrating Cython.
One of the approaches I used to have, was to write the test function in pure C, compile it with a C compiler (getting distutils to find and invoke the compiler for me) then load the library into Python with ctypes, and execute the function.
This worked swimmingly until distutils started embedding the python version and the platform in the name of the file it generates.
In the past I could persuade distutils to compile a C source file called C.c into a library called C.so in the working directory: recent versions of distutils insist on mangling the output name into something of the form build/temp.linux-x86_64-3.6 or (depending on exactly what distutils features I use) some other variaton on that theme.
Is there any way to persuade current versions of distutils to simply call the output C.so in the current working directory? (Alternatively, is there some way to reliably and easily tell ctypes where the library produced by distutils resides?)
[Bonus: How can this idea be expressed portably across Linux, OS X and Windows?]
=================================================================
Edit: for completeness, here is how I used to do it successfully in the past:
pure_C_setup.py:
from distutils.core import setup, Extension
setup(name="ctypes-test",
ext_modules = [Extension("C", ["C.c"])])
With the above setup file, the command python pure_C_setup.py install --install-lib=. used to produce C.so in the working directory; today it produces build/lib.linux-x86_64-3.6/C.cpython-36m-x86_64-linux-gnu.so
Not platform, not even compiler independent, but you might be able to use Extension's extra_link_args to achieve what you want.
For VCPP 2015:
setup(name="ctypes-test",
ext_modules = [Extension("C", ["C.c"], extra_link_args="/OUT:C.pyd")])
I'm trying to use a python package from IronPython.
Everything works fine if I import regular python modules.
But when I try to do the following:
import win32ui
I get:
No module named win32ui
I've hunted through the code in IronPython.Runtime.Importer and there's no mention of .pyd
Anyone know a way around this?
You can check out IronClad which is working to provide this support. It may or may not work w/ your PYD of choice.
A .pyd file is a DLL. So unless IronPython (which is written in .net) can correctly load C DLLs written for CPython, you might be out of luck.
Update
In fact, according to the IronPython FAQ, you are unfortunately unable to import .pyd files:
Q: How do I build and call into PYD libraries?
A: IronPython does not support using PYDs built for CPython since they
leverage implementation details of CPython. You can get a similar
effect for new "PYD"s you would like to implement by writing them in C#
or VB and building a DLL for .NET.