6 ms·

The only reason this is a problem is because a language like Python is interpreted. Programs are usually deployed as source. This means the platform that will e

The only reason this is a problem is because a language like Python is interpreted. Programs are usually deployed as source. This means the platform that will execute the program needs to have Python installed, and that environment comes into play. With C you are usually delivering a compiled binary executable. If they did add a feature to C, you could use the new compiler with the new feature on your local development environment. It wouldn't matter at all to the place you deployed it, as long as you make a compatible binary. There do exist some tools to build binaries from Python, and other interpreted languages. They still need a lot of work. I would say that it should even be a part of python itself. I see no reason that I shouldn't be able to do something like python --compile hello.py > hello ./hello "Hello World" Or on Windows python --compile hello.py > hello.exe Now the target environment doesn't even need Python to be installed at all!

signa11 9y ago
,---- | With C you are usually delivering a compiled binary executable. If | they did add a feature to C, you could use the new compiler on your | local development environment, and it wouldn't matter at all to the | place you deployed it as long as you delivery a compatible binary. `---- with C probably not, which has not been accumulating features for like forever. C++ however, is another beast. some machines might not have new fangled c++11 stuff installed on them. sources that use these features, might have a tough time. as an example: c++11 introduced unique_ptr to the world. if you try to use that, you might notice that not all of c++ gets compiled into the binary. some of it e.g. libstdc++ lives on the disk as well, and gets linked during runtime. this can now be fixed via some '-rpath' incantations or '-static' linking (which increases the size etc.) perhaps then you might start looking at 'LD_LIBRARY_PATH' ? what about creating your own little sandboxes e.g. via chroot's ? but if you step back a bit, all this boils down to is creating little environments within which programs, which are supposed to be running from command-line are now sequestered... what a grate mess :)
monetus 9y ago
I'm not sure about python's, but thankfully tcl's interpreter is so small you can package it with all your other code. Edit: Is there a python equivalent of tclquadcode, https://core.tcl.tk/tclquadcode/dir?ci=tip https://core.tcl.tk/tclquadcode/dir?ci=tip - which should compile tcl into llvm's IR?
wyldfire 9y ago
> With C you are usually delivering a compiled binary executable. If they did add a feature to C, you could use the new compiler with the new feature on your local development environment. It wouldn't matter at all to the place you deployed it, as long as you make a compatible binary. You're mistaken. C has added features to its standard library before. It allows you to detect the presence of this feature at compile-time with a preprocessor definition. But if your compiler supports the feature and your target does not, in most cases you will get a fatal error regarding symbol resolution from the loader. This problem is remarkably similar to the one faced by Python developers. The difference is that Python's philosophy includes a statement regarding "batteries included", so its standard library has taken on more frequent additions than C's. In order to portably target multiple environments, you will occasionally need to handle ImportError (disable a product feature or have a fallback implementation) or (in C, e.g.) provide a fallback implementation designated as "weak". Or forego portability, capitalize on the feature, and raise the requirements for your target.
- AnimalMuppet 9y ago
  By "from the loader", do you mean the linker? Most of us regard that as part of compiling. Or are using .dll or .so files? For a static C program, regarding compiling and linking as part of the same (build) process, I see only two possible outcomes. Either I get an error at build time, or I get an executable that I can drop on the target that will run. The one exception I can see to this is if the program is going to make an OS call that some versions of the OS don't support.
  - wyldfire 9y ago
    > By "from the loader", do you mean the linker? Most of us regard that as part of compiling. No, I meant from the dynamic loader (like ld.so). > Or are using .dll or .so files? Yes, that's a very common idiom for libc and libstdc++/libc++. Yes, you're right that statically linked binaries will not suffer this dependency and usually end up more portable (often at a cost of some memory and security/maintenance). > The one exception I can see to this is if the program is going to make an OS call that some versions of the OS don't support. Exactly. This is actually a little less rare than C library features, from what I've seen. But, here, like ImportError and providing weak impls, you can handle ENOSYS.
sifoo 9y ago
This is one of the fundamental features of Cixl [0]. I wish more interpreters would support emitting their host language; having the option of compiling statically linked executables in combination with a REPL running the same code is a very nice place to be. https://github.com/basic-gongfu/cixl#compiling https://github.com/basic-gongfu/cixl#compiling
krylon 9y ago
FWIW, on Windows there is py2exe[1], but it is nowhere nearly as convenient as what you have in mind. It basically wraps your script along with any dependencies and the python runtime into a folder. But at least you can copy that folder to any other Windows machine and run the executable, and it will mostly "just work". http://www.py2exe.org/ http://www.py2exe.org/
bklaasen 9y ago
Nuitka, the Python compiler, fits the bill here: http://nuitka.net/doc/user-manual.html#overview http://nuitka.net/doc/user-manual.html#overview

signa11 9y ago

,---- | With C you are usually delivering a compiled binary executable. If | they did add a feature to C, you could use the new compiler on your | local development environment, and it wouldn't matter at all to the | place you deployed it as long as you delivery a compatible binary. `---- with C probably not, which has not been accumulating features for like forever. C++ however, is another beast. some machines might not have new fangled c++11 stuff installed on them. sources that use these features, might have a tough time. as an example: c++11 introduced unique_ptr to the world. if you try to use that, you might notice that not all of c++ gets compiled into the binary. some of it e.g. libstdc++ lives on the disk as well, and gets linked during runtime. this can now be fixed via some '-rpath' incantations or '-static' linking (which increases the size etc.) perhaps then you might start looking at 'LD_LIBRARY_PATH' ? what about creating your own little sandboxes e.g. via chroot's ? but if you step back a bit, all this boils down to is creating little environments within which programs, which are supposed to be running from command-line are now sequestered... what a grate mess :)

monetus 9y ago

I'm not sure about python's, but thankfully tcl's interpreter is so small you can package it with all your other code. Edit: Is there a python equivalent of tclquadcode, https://core.tcl.tk/tclquadcode/dir?ci=tip https://core.tcl.tk/tclquadcode/dir?ci=tip - which should compile tcl into llvm's IR?

wyldfire 9y ago

> With C you are usually delivering a compiled binary executable. If they did add a feature to C, you could use the new compiler with the new feature on your local development environment. It wouldn't matter at all to the place you deployed it, as long as you make a compatible binary. You're mistaken. C has added features to its standard library before. It allows you to detect the presence of this feature at compile-time with a preprocessor definition. But if your compiler supports the feature and your target does not, in most cases you will get a fatal error regarding symbol resolution from the loader. This problem is remarkably similar to the one faced by Python developers. The difference is that Python's philosophy includes a statement regarding "batteries included", so its standard library has taken on more frequent additions than C's. In order to portably target multiple environments, you will occasionally need to handle ImportError (disable a product feature or have a fallback implementation) or (in C, e.g.) provide a fallback implementation designated as "weak". Or forego portability, capitalize on the feature, and raise the requirements for your target.

AnimalMuppet 9y ago
By "from the loader", do you mean the linker? Most of us regard that as part of compiling. Or are using .dll or .so files? For a static C program, regarding compiling and linking as part of the same (build) process, I see only two possible outcomes. Either I get an error at build time, or I get an executable that I can drop on the target that will run. The one exception I can see to this is if the program is going to make an OS call that some versions of the OS don't support.
- wyldfire 9y ago
  > By "from the loader", do you mean the linker? Most of us regard that as part of compiling. No, I meant from the dynamic loader (like ld.so). > Or are using .dll or .so files? Yes, that's a very common idiom for libc and libstdc++/libc++. Yes, you're right that statically linked binaries will not suffer this dependency and usually end up more portable (often at a cost of some memory and security/maintenance). > The one exception I can see to this is if the program is going to make an OS call that some versions of the OS don't support. Exactly. This is actually a little less rare than C library features, from what I've seen. But, here, like ImportError and providing weak impls, you can handle ENOSYS.

sifoo 9y ago

This is one of the fundamental features of Cixl [0]. I wish more interpreters would support emitting their host language; having the option of compiling statically linked executables in combination with a REPL running the same code is a very nice place to be. https://github.com/basic-gongfu/cixl#compiling https://github.com/basic-gongfu/cixl#compiling

krylon 9y ago

FWIW, on Windows there is py2exe[1], but it is nowhere nearly as convenient as what you have in mind. It basically wraps your script along with any dependencies and the python runtime into a folder. But at least you can copy that folder to any other Windows machine and run the executable, and it will mostly "just work". http://www.py2exe.org/ http://www.py2exe.org/

bklaasen 9y ago

Nuitka, the Python compiler, fits the bill here: http://nuitka.net/doc/user-manual.html#overview http://nuitka.net/doc/user-manual.html#overview