How to use protobuf-csharp-port from unix - linux

We've been using protocol buffers, and are generating the c++ and python files with protoc, and the c# files with protobuf-csharp-port. At the moment these are done separately, the c++ and python from linux and the c# from windows. We'd like to have one script generate all of these, running in linux.
To do this I'm trying to run ProtoGen.exe with mono, but it's not producing any output. The following command runs, but produces no cs files, and no errors.
mono ../cs/Packages/Google.ProtocolBuffers/tools/ProtoGen.exe --protoc_dir=/usr/local/bin/ ./subdir/simple_types.proto
I've got a feeling that I'm missing something simple.

I don't think I've tried running protoc from ProtoGen.exe on Linux. I'm surprised that it doesn't have any errors, but we can definitely look into that. (If you fancy raising an issue, that would be really helpful - or I'll do it when I get the chance.)
For the moment, I suggest that you run protoc first, using --descriptor_set_out to produce a binary (protobuf) version of the .proto file. That's what ProtoGen.exe is trying to do first, and failing by the sounds of it.
Once you've got the binary version of your message descriptor (I'd call it simple_types.pb), you can run ProtoGen.exe on that. It's been a while since I've done this, but I believe you should be able to just run
mono ../cs/Packages/Google.ProtocolBuffers/tools/ProtoGen.exe ./subdir/simple_types.pb
... and it should magically work.
As a horrible alternative, you could try symlinking protoc.exe to protoc in your binary directory. Fundamentally I suspect that's what's going wrong :)

my script
protoc "--proto_path=$SRC_DIR" "--descriptor_set_out=x.protobin" --include_imports $SRC_DIR/x.proto
mono $PRJ_HOME/Google.ProtocolBuffers.2.4.1.521/tools/ProtoGen.exe -line_break=Unix x.protobin
protoc and mono were installed via distrib package manager :
# archlinux
pacman -S protobuf mono

Related

Include WinPcap in a Python binary

I made a Python 3 program that uses Scapy, then I used pyinstaller to generate a binary and it works fine, but there’s always the need to install WinPcap separately to be able to use the binary.
Is there a way to include WinPcap/npcap to the binary, so the user won’t bother installing additional software?
Winpcap isn't just a library. It actually installs a service and copies a few DLLS to C:/Windows/system32.
You'll need to install it.
Moreover, the installer doesn't support command line installation :/ the only thing that currently works is the chocolatey package, which uses AutoHotKey and is kinda messy.

Allow my friends to run my python script? [duplicate]

This question already has answers here:
Create a single executable from a Python project [closed]
(3 answers)
Closed 1 year ago.
I'm building a Python application and don't want to force my clients to install Python and modules.
So, is there a way to compile a Python script to be a standalone executable?
You can use PyInstaller to package Python programs as standalone executables. It works on Windows, Linux, and Mac.
PyInstaller Quickstart
Install PyInstaller from PyPI:
pip install pyinstaller
Go to your program’s directory and run:
pyinstaller yourprogram.py
This will generate the bundle in a subdirectory called dist.
pyinstaller -F yourprogram.py
Adding -F (or --onefile) parameter will pack everything into single "exe".
pyinstaller -F --paths=<your_path>\Lib\site-packages yourprogram.py
running into "ImportError" you might consider side-packages.
pip install pynput==1.6.8
still runing in Import-Erorr - try to downgrade pyinstaller - see Getting error when using pynput with pyinstaller
For a more detailed walkthrough, see the manual.
You can use py2exe as already answered and use Cython to convert your key .py files in .pyc, C compiled files, like .dll in Windows and .so on Linux.
It is much harder to revert than common .pyo and .pyc files (and also gain in performance!).
You might wish to investigate Nuitka. It takes Python source code and converts it in to C++ API calls. Then it compiles into an executable binary (ELF on Linux). It has been around for a few years now and supports a wide range of Python versions.
You will probably also get a performance improvement if you use it. It is recommended.
Yes, it is possible to compile Python scripts into standalone executables.
PyInstaller can be used to convert Python programs into stand-alone executables, under Windows, Linux, Mac OS X, FreeBSD, Solaris, and AIX. It is one of the recommended converters.
py2exe converts Python scripts into only executable on the Windows platform.
Cython is a static compiler for both the Python programming language and the extended Cython programming language.
I would like to compile some useful information about creating standalone files on Windows using Python 2.7.
I have used py2exe and it works, but I had some problems.
It has shown some problems for creating single files in Windows 64 bits: Using bundle_files = 1 with py2exe is not working;
It is necessary to create a setup.py file for it to work. http://www.py2exe.org/index.cgi/Tutorial#Step2;
I have had problems with dependencies that you have to solve by importing packages in the setup file;
I was not able to make it work together with PyQt.
This last reason made me try PyInstaller http://www.pyinstaller.org/.
In my opinion, it is much better because:
It is easier to use.
I suggest creating a .bat file with the following lines for example (pyinstaller.exe must be in in the Windows path):
pyinstaller.exe --onefile MyCode.py
You can create a single file, among other options (https://pyinstaller.readthedocs.io/en/stable/usage.html#options).
I had only one problem using PyInstaller and multiprocessing package that was solved by using this recipe: https://github.com/pyinstaller/pyinstaller/wiki/Recipe-Multiprocessing.
So, I think that, at least for python 2.7, a better and simpler option is PyInstaller.
And a third option is cx_Freeze, which is cross-platform.
pyinstaller yourfile.py -F --onefile
This creates a standalone EXE file on Windows.
Important note 1: The EXE file will be generated in a folder named 'dist'.
Important note 2: Do not forget --onefile flag
You can install PyInstaller using pip install PyInstaller
NOTE: In rare cases there are hidden dependencies...so if you run the EXE file and get missing library error (win32timezone in the example below) then use something like this:
pyinstaller --hiddenimport win32timezone -F "Backup Program.py"
I like PyInstaller - especially the "windowed" variant:
pyinstaller --onefile --windowed myscript.py
It will create one single *.exe file in a distination/folder.
You may like py2exe. You'll also find information in there for doing it on Linux.
Use py2exe.... use the below set up files:
from distutils.core import setup
import py2exe
from distutils.filelist import findall
import matplotlib
setup(
console = ['PlotMemInfo.py'],
options = {
'py2exe': {
'packages': ['matplotlib'],
'dll_excludes': ['libgdk-win32-2.0-0.dll',
'libgobject-2.0-0.dll',
'libgdk_pixbuf-2.0-0.dll']
}
},
data_files = matplotlib.get_py2exe_datafiles()
)
I also recommend PyInstaller for better backward compatibility such as Python 2.3 - 2.7.
For py2exe, you have to have Python 2.6.
For Python 3.2 scripts, the only choice is cx_Freeze. Build it from sources; otherwise it won't work.
For Python 2.x I suggest PyInstaller as it can package a Python program in a single executable, unlike cx_Freeze which outputs also libraries.
Since it seems to be missing from the current list of answers, I think it is worth mentioning that the standard library includes a zipapp module that can be used for this purpose. Its basic usage is just compressing a bunch of Python files into a zip file with extension .pyz than can be directly executed as python myapp.pyz, but you can also make a self-contained package from a requirements.txt file:
$ python -m pip install -r requirements.txt --target myapp
$ python -m zipapp -p "interpreter" myapp
Where interpreter can be something like /usr/bin/env python (see Specifying the Interpreter).
Usually, the generated .pyz / .pyzw file should be executable, in Unix because it gets marked as such and in Windows because Python installation usually registers those extensions. However, it is relatively easy to make a Windows executable that should work as long as the user has python3.dll in the path.
If you don't want to require the end user to install Python, you can distribute the application along with the embeddable Python package.
py2exe will make the EXE file you want, but you need to have the same version of MSVCR90.dll on the machine you're going to use your new EXE file.
See Tutorial for more information.
You can find the list of distribution utilities listed at Distribution Utilities.
I use bbfreeze and it has been working very well (yet to have Python 3 support though).
Not exactly a packaging of the Python code, but there is now also Grumpy from Google, which transpiles the code to Go.
It doesn't support the Python C API, so it may not work for all projects.
Using PyInstaller, I found a better method using shortcut to the .exe rather than making --onefile. Anyway, there are probably some data files around and if you're running a site-based app then your program depends on HTML, JavaScript, and CSS files too. There isn't any point in moving all these files somewhere... Instead what if we move the working path up?
Make a shortcut to the EXE file, move it at top and set the target and start-in paths as specified, to have relative paths going to dist\folder:
Target: %windir%\system32\cmd.exe /c start dist\web_wrapper\web_wrapper.exe
Start in: "%windir%\system32\cmd.exe /c start dist\web_wrapper\"
We can rename the shortcut to anything, so renaming to "GTFS-Manager".
Now when I double-click the shortcut, it's as if I python-ran the file! I found this approach better than the --onefile one as:
In onefile's case, there's a problem with a .dll missing for the Windows 7 OS which needs some prior installation, etc. Yawn. With the usual build with multiple files, no such issues.
All the files that my Python script uses (it's deploying a tornado web server and needs a whole freakin' website worth of files to be there!) don't need to be moved anywhere: I simply create the shortcut at top.
I can actually use this exact same folder on Ubuntu (run python3 myfile.py) and Windows (double-click the shortcut).
I don't need to bother with the overly complicated hacking of .spec file to include data files, etc.
Oh, remember to delete off the build folder after building. It will save on size.
Use Cython to convert to C, compile, and link with GCC.
Another could be, make the core functions in C (the ones you want to make hard to reverse), compile them and use Boost.Python to import the compiled code (plus you get a much faster code execution). Then use any tool mentioned to distribute.
I'm told that PyRun is also an option. It currently supports Linux, FreeBSD and Mac OS X.

Can't run NodeSchool workshops in Git Bash. "TypeError: process.stdin.setRawMode is not a function"

From the research I did for the topic, I saw some recommendations to install tty.js with npm, but it wouldn't install as well - some sort of python exe missing from the system error.
I am able to run the program from Git CMD but it is all confusing for me because I am familiar with unix based consoles :(
The way I installed node.js and npm : All was doen with the installer provided by node.js.
Any insights? Thank you in advance!
I have installed tty.js in a linux enviroment and it works great, you should some building essentials installed, such as:
gcc
g++
make
As well as Python 2.7. When installing using npm, it will look for all the dependencies and as I understand it will compile some C code that does the magic behind the scenes. I haven't tried it on Windows, but what I have seen there is the C code designed for windows, so it probably will run.
Maybe I will be of more help if you copy what you get on the npm installation.
have you tried using Git Bash? That is what I used for the most part as well and acts more unix like. If you're on a PC, an alternative is using ConEMU as they give you a shell that is unix like. Just wanted to give you some options if you're still running into trouble, I know this is super late :)

How to build libfetch in linux?

As is known for us all, source code for libfetch.so is not originally designed for redhat linux,and I have searched and tried many times, failed ,but I know someone has successfully made it previously.
Of course, commonly used ./confgure --parameter && make && make install will fail immediately, for the simple reason that it has no configure file(or something like that) at all!
source code download: http://www.filewatcher.com/m/libfetch-2.33.tar.gz.46611-0.html
so, can someone of you help me ?
I was able to build libfetch on Linux Mint using the Makefile which is available from the Alpine Linux aports repo. (It is very different from the BSD Makefile which comes with the libfetch source.) All the other source code was unchanged.

Mono framework shebang linux

I have a c# source file. Is there any way to put something like #!/usr/bin/env mono, so it will be compiled and then run as executable:
For python for example, i'll do like this:
#!/usr/bin/env python
In fact, what I want is to run the script without calling "mono the.exe", after compiling. I want something like "./the.exe".
EDIT: I just noticed you want to do this for a single source file—for a single source file. This is almost supported by the csharp REPL that ships with Mono. However, the REPL spits out a syntax error because it doesn't understand the shebang line and sees it as a preprocessor definition. If I misunderstood and you were talking about a compiled assembly, the below text still applies. /EDIT
You can't use shebangs, because .exe files produced by Mono are PE executables, just like on Windows. They contain CIL, not a script.
What you can do though is produce a small shell script that runs mono your.exe and use that, or you can use the Linux kernel's binfmts support, as outlined here.
I think you may be able to use update-binfmts to register mono as the interpreter for (compiled) mono programs.
Try update-binfmts --display and see if the output includes something like:
cli (enabled):
package = mono-common
type = magic
offset = 0
magic = MZ
mask =
interpreter = /usr/bin/cli
detector = /usr/lib/cli/binfmt-detector-cli

Resources