tinypy, a really tiny Python
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
tinypy, a really tiny Python
I reported recently the problem of Wirbel generating huge executables, so I looked around at what other Python compilers/interpreters are out there. Specifically, what I'm looking for is small size. An interpreter is still within my acceptable range, as they compile to bytecode first -- in fact, I think that the "full" Python has an option to generate a bytecode file. Bytecode is kind of half-way between a pure source-code-interpreter and a native-code-compiler.
Anyway, the first one that I have tested is 'tinypy'. It took a lot of messing around, but I managed to compile it statically in the uClibc rootfs -- the interpreter executable is just 131KB! -- that is static, totally standalone, so can reside in the initial ramdisk and will work in any Linux distro and all old versions of Puppy.
Homepage: http://tinypy.org/
I have packaged it up as 'tinypy-1.1-static.pet', see attached.
So far I have only tested "hello world" -- like Wirbel, 'print' is a function, so you need brackets:
print("hello world")
The main problem with testing it is the lack of documentation -- I will have to study the source code to find out what functions etc. are available.
Anyway, the first one that I have tested is 'tinypy'. It took a lot of messing around, but I managed to compile it statically in the uClibc rootfs -- the interpreter executable is just 131KB! -- that is static, totally standalone, so can reside in the initial ramdisk and will work in any Linux distro and all old versions of Puppy.
Homepage: http://tinypy.org/
I have packaged it up as 'tinypy-1.1-static.pet', see attached.
So far I have only tested "hello world" -- like Wirbel, 'print' is a function, so you need brackets:
print("hello world")
The main problem with testing it is the lack of documentation -- I will have to study the source code to find out what functions etc. are available.
- Attachments
-
- tinypy-1.1-static.pet
- (56.2 KiB) Downloaded 1407 times
[url]https://bkhome.org/news/[/url]
Nice find Barry!
Another thing along those lines: the cooledit editor contains a python interpretor, but not as a separate entity. Still, looking at the code might be worth something. I keep cooledit around anyway because of two other reasons -it is good for editing binaries and because of the coolman man-page reader. The two together are well worrht the space. I rolled a static version of the man-page reader into my RTFM man-page reader/browser progam.
While I have your attention, I posted elsewhere asking for the seamonkey patch for the 'bareview' feature. Can you supply a patch or a link to the sources? amigo@ibiblio.org
Another thing along those lines: the cooledit editor contains a python interpretor, but not as a separate entity. Still, looking at the code might be worth something. I keep cooledit around anyway because of two other reasons -it is good for editing binaries and because of the coolman man-page reader. The two together are well worrht the space. I rolled a static version of the man-page reader into my RTFM man-page reader/browser progam.
While I have your attention, I posted elsewhere asking for the seamonkey patch for the 'bareview' feature. Can you supply a patch or a link to the sources? amigo@ibiblio.org
In my own experience, most of what you can do with Python comes from imported libraries. Although you can have a small interpreter wouldn't it also require at least a basic set of libraries? e.g. os, sys, re, etc.
A language is as rich as the libraries available.
Besides, at least for what I saw at this point it is still a work pretty much in progress that does not comply with the full python syntax.
So python programs writen in Tinypy may run on the full python but python applications writen for the standard interpreter may not run in Tinypy.
A language is as rich as the libraries available.
Besides, at least for what I saw at this point it is still a work pretty much in progress that does not comply with the full python syntax.
As you pointed out "print" is a good example.according to the web page wrote:a fairly decent subset of python
So python programs writen in Tinypy may run on the full python but python applications writen for the standard interpreter may not run in Tinypy.
[url]http://rarsa.blogspot.com[/url] Covering my eclectic thoughts
[url]http://www.kwlug.org/blog/48[/url] Covering my Linux How-to
[url]http://www.kwlug.org/blog/48[/url] Covering my Linux How-to
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
If anyone is interested, I got the latest tinypy out of SVN and compiled it with Dietlibc. This is how:
The "proper" Python and Dietlibc are required to compile, and both of these are in the Puppy4 'devx' file.
The stripped executable is even smaller, just 127KB. My previous PET package has the 'tinypy' at /sbin, so just replace that.
Attached:
Code: Select all
# svn checkout http://tinypy.googlecode.com/svn/trunk/ tinypy-read-only
I modified setup.py, changed '-O3' to '-O2'.
# python setup.py tinypy -clinux NOTE: could append this but makes executable bigger: 'math random'
Final step:
gcc -std=c89 -Wall -Wc++-compat -O2 mymain.c -lm -o ../build/tinypy
Now I have done it with dietlibc:
# diet gcc -nostdinc -std=c89 -Wall -Wc++-compat -O2 mymain.c -lm -o ../build/tinypy
The stripped executable is even smaller, just 127KB. My previous PET package has the 'tinypy' at /sbin, so just replace that.
Attached:
- Attachments
-
- tinypy.gz
- (47.85 KiB) Downloaded 974 times
[url]https://bkhome.org/news/[/url]
I'm wondering what the attraction is of Python.
From what I've read, to write gui apps you end up with an order of magnitude more code using PyGTK as opposed to Tcl/tk or gnocl. Is that the fault of PyGTK itself rather than Python?
From what I've read, to write gui apps you end up with an order of magnitude more code using PyGTK as opposed to Tcl/tk or gnocl. Is that the fault of PyGTK itself rather than Python?
Do you know a good gtkdialog program? Please post a link here
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
Yes, although gtkdialog is EXTREMELY limited, and that doesn't answer the question
On your blog you said you were looking for a language that wasn't interpreted; and said python was, even if it is compiled. Maybe I've misunderstood something, but I was curious as to why you're going after python now.
On your blog you said you were looking for a language that wasn't interpreted; and said python was, even if it is compiled. Maybe I've misunderstood something, but I was curious as to why you're going after python now.
Do you know a good gtkdialog program? Please post a link here
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
My understanding is that a lot of Python modules are written in Python, which means they would get converted to bytecode at some point, either before or at runtime. Apart from the conversion delay, the size of such functions will be large and execution slow.disciple wrote:Yes, although gtkdialog is EXTREMELY limited, and that doesn't answer the question
On your blog you said you were looking for a language that wasn't interpreted; and said python was, even if it is compiled. Maybe I've misunderstood something, but I was curious as to why you're going after python now.
I don't know anything about PyGTK, whether it is bloated/slow or not.
In theory, it is possible to write Python modules in C or C++ and that make full use of the underlying native system shared libraries. So, it seems to me that in theory the "full" Python does not really have to be as big and slow as it is.
The full Python can compile an application to bytecode, but an interpreter is still required.
Regarding tinypy, it is also a bytecode interpreter.
The thing is, we can get good performance out of a bytecode interpreted program, as long as all the applications and libraries that it uses are natively-compiled. In the case of tinypy I commented that some of the functions were written in Python thus requiring runtime bytecode interpretation, which is not the most efficient.
Yes, a true Python compiler would be the best. I looked at shed-skin but "hello world" was alarmingly big. The developer of Wirbel, Mathias, has responded to my complaint about the executables being too big and says that the compiler does a lot of inlining, which he will look into -- but that will take time.
Actually, my personal interest is to find a very easy-to-understand compiler/interpreter that I can modify, create my own extensions. Tinypy is the closest that I've found so far, remarkably small, easy to read C code.
[url]https://bkhome.org/news/[/url]
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Answering as why I'm "going after Python now":
I'm thinking about including the "full" Python in Woof, as cutdown as I can get away with, because Python is so heavily used in Linux these days. So many applications require Python, like Inkscape for example. The Rox Filer people have other apps than need Python. If you go to www.gnome-files.org and look around, almost every second app is written in Python and uses PyGTK.
So, I am just bowing to the reality. But, whether I do take the plunge and go for the "full" Python, I still don't know.
Tinypy has nothing to do with the above. It is something that I am playing with in my ongoing search for something to upgrade to from Bash coding. In particular, something that I can myself hack on.
So, tinypy + gtkdialog + low-level-system-hacks is of interest to me.
But why Python? Why not a basic/C/something-else compiler/interpreter? Basic and C are very crude in comparison, really crude. Python code has such a clear and concise and readable syntax, at least for me. The fundamental object oriented underpinnings give it inherent power and expressiveness in the code.
I am told and have read many times, how much better the functional languages are, such as OCaml and Haskel, but I don't understand them and don't want to go into a long learning curve. With Python, I felt at home right away, and can progress from plain structured programming into object-oriented and even some functional coding at my leisure -- Python is so adaptable to all these levels of coding skill.
heh heh, do note that I'm just playing. Who knows, I might end up just staying with bash for Woof.
I'm thinking about including the "full" Python in Woof, as cutdown as I can get away with, because Python is so heavily used in Linux these days. So many applications require Python, like Inkscape for example. The Rox Filer people have other apps than need Python. If you go to www.gnome-files.org and look around, almost every second app is written in Python and uses PyGTK.
So, I am just bowing to the reality. But, whether I do take the plunge and go for the "full" Python, I still don't know.
Tinypy has nothing to do with the above. It is something that I am playing with in my ongoing search for something to upgrade to from Bash coding. In particular, something that I can myself hack on.
So, tinypy + gtkdialog + low-level-system-hacks is of interest to me.
But why Python? Why not a basic/C/something-else compiler/interpreter? Basic and C are very crude in comparison, really crude. Python code has such a clear and concise and readable syntax, at least for me. The fundamental object oriented underpinnings give it inherent power and expressiveness in the code.
I am told and have read many times, how much better the functional languages are, such as OCaml and Haskel, but I don't understand them and don't want to go into a long learning curve. With Python, I felt at home right away, and can progress from plain structured programming into object-oriented and even some functional coding at my leisure -- Python is so adaptable to all these levels of coding skill.
heh heh, do note that I'm just playing. Who knows, I might end up just staying with bash for Woof.
[url]https://bkhome.org/news/[/url]
Python and/or Lua
I once "tried" to "learn" Python, but I was a bit lazy and never finished the exercise. Nevertheless, Python sits up there as one of the languages I wish I would learn!
I do have a problem with the size of full Python, but that's because I have a love affair with ancient Palm handheld devices. For that latter reason, I have started "trying" to learn Lua, since a version 4 of that can run on even an old Palm III... I also note that Lua is used in lots of games programming nowadays (to alter gameplay in the likes of World of Warcraft). Actually, I hardly ever play computer games, but with computer games overtaking video and CD's as a consumer item I guess there is a market for games programmers and Lua must be a useful wee skill. Also the Lua interpreter is really tiny. It is so tiny, I can't help think that it should always be slotted into Puppy releases, since it adds almost no weight in terms of distribution size at all. Of course, I know there is Murga Lua, which I presume is a customised version of Lua which utilises some graphics library or other. But Lua can also be used simply as a scripting language too, and hence would also be perfect for use with gtkdialog, and it is relatively fast according to all reports, and one of the easiest languages of all to learn.
The other thing old me likes about Lua so far, is that it is not object oriented "per se" but can be used to produce classes, and objects and inheritance and so on, if you want to adopt that approach. For those who can also program in C or C++, Lua can simply be linked into your program (giving you full Lua scripting facilities as part of your program... That seems to be what the World of Warcraft people do with it).
Having been looking into this on and off for years, I have to say that Lua looks to me like a huge winner. Python is terrific too, but the full version, at least, has grown frighteningly large and complex and the tiny versions lack power, and compatibility I fear. Time all Puppians learned Lua and then the Puppy developer programming force would be huge! It is a damn site easier and more flexible than bash yet tons of us can write shell scripts (+ gtkdialog).
I do have a problem with the size of full Python, but that's because I have a love affair with ancient Palm handheld devices. For that latter reason, I have started "trying" to learn Lua, since a version 4 of that can run on even an old Palm III... I also note that Lua is used in lots of games programming nowadays (to alter gameplay in the likes of World of Warcraft). Actually, I hardly ever play computer games, but with computer games overtaking video and CD's as a consumer item I guess there is a market for games programmers and Lua must be a useful wee skill. Also the Lua interpreter is really tiny. It is so tiny, I can't help think that it should always be slotted into Puppy releases, since it adds almost no weight in terms of distribution size at all. Of course, I know there is Murga Lua, which I presume is a customised version of Lua which utilises some graphics library or other. But Lua can also be used simply as a scripting language too, and hence would also be perfect for use with gtkdialog, and it is relatively fast according to all reports, and one of the easiest languages of all to learn.
The other thing old me likes about Lua so far, is that it is not object oriented "per se" but can be used to produce classes, and objects and inheritance and so on, if you want to adopt that approach. For those who can also program in C or C++, Lua can simply be linked into your program (giving you full Lua scripting facilities as part of your program... That seems to be what the World of Warcraft people do with it).
Having been looking into this on and off for years, I have to say that Lua looks to me like a huge winner. Python is terrific too, but the full version, at least, has grown frighteningly large and complex and the tiny versions lack power, and compatibility I fear. Time all Puppians learned Lua and then the Puppy developer programming force would be huge! It is a damn site easier and more flexible than bash yet tons of us can write shell scripts (+ gtkdialog).
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
I have found that you can cutdown full Python's .py to a great extent, by deleting all of the .pyo and .pyc files and then thoroughly running all of the python programs that you think you may run. This will generate .pyo/.pyc files for all of the .py files that are used (unless you pass python the -B option). Then delete all of the .py files that do not have a matching .py or .pyc file(or move them to devx). Once all of those are removed you can delete all .py and .pyc files.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
Re: Python and/or Lua
I have it running on a Palm OS 5 device. There's a Plau 2 rev for Palm OS as well.mcewanw wrote: I do have a problem with the size of full Python, but that's because I have a love affair with ancient Palm handheld devices. For that latter reason, I have started "trying" to learn Lua, since a version 4 of that can run on even an old Palm III...
Lua is showing up in a lot of places. It's designed to be embeddable, and the Geany editor provided with Puppy can be scripted in Lua. Geany is based on the Scintilla edit control, and several other editors in that family use Lua, like SciTE-it, a variant of SciTE that uses Lua for dynamic lexing. And the maintainer of SciTE-it has an editor called TextAdept is is 2K lines of C core and a boatload of Lua scripting. It's intended to be extensible with Lua the same way Gnu Emacs can be extended with Lisp.I also note that Lua is used in lots of games programming nowadays (to alter gameplay in the likes of World of Warcraft). Actually, I hardly ever play computer games, but with computer games overtaking video and CD's as a consumer item I guess there is a market for games programmers and Lua must be a useful wee skill.
As I recall, Damn Small Linux makes extensive use of Lua.Also the Lua interpreter is really tiny. It is so tiny, I can't help think that it should always be slotted into Puppy releases, since it adds almost no weight in terms of distribution size at all. Of course, I know there is Murga Lua, which I presume is a customised version of Lua which utilises some graphics library or other. But Lua can also be used simply as a scripting language too, and hence would also be perfect for use with gtkdialog, and it is relatively fast according to all reports, and one of the easiest languages of all to learn.
While I recognize the size penalty, I'm in favor of full releases of Perl, Python, TclTk, and Lua in Puppy. If they don't get included in the stock ISO, recent versions should be available in the current branch on Ibiblio.
As mentioned, getting embedded like that is a design goal for the language.The other thing old me likes about Lua so far, is that it is not object oriented "per se" but can be used to produce classes, and objects and inheritance and so on, if you want to adopt that approach. For those who can also program in C or C++, Lua can simply be linked into your program (giving you full Lua scripting facilities as part of your program... That seems to be what the World of Warcraft people do with it).
As long as no one suggests replacing existing Bash scripting with Lua.Having been looking into this on and off for years, I have to say that Lua looks to me like a huge winner. Python is terrific too, but the full version, at least, has grown frighteningly large and complex and the tiny versions lack power, and compatibility I fear. Time all Puppians learned Lua and then the Puppy developer programming force would be huge! It is a damn site easier and more flexible than bash yet tons of us can write shell scripts (+ gtkdialog).
______
Dennis
- prehistoric
- Posts: 1744
- Joined: Tue 23 Oct 2007, 17:34
why not a translator?
While people are always arguing about one language vs. another, or which libraries you absolutely must include, there is an option which keeps getting overlooked. Why not translate the full language into a small subset that is easy to implement, and carries little overhead?
The print syntax described is a perfect example. You don't need any real knowledge of language semantics to do such translations. Do them once, when you adopt a particular source for a Puppy application, and the remaining support can be done in the subset language.
When you get into the business of languages, or libraries, that support everything people might want to do, you are headed for bloat.
I want to put in another vote for Lua. This has so little overhead, and can easily be extended in so many ways, it would make a great basis for scripts. Our problem is that we don't have a lot of Lua scripts for things we want to do. Possible solution: translate scripts in some existing language to Lua. This might not be possible to completely automate, but I'm certain one could do translations which would handle 90+% of the work. Even if the result is far from optimal, 90% of the time this doesn't matter. Besides, there are more programmers who know how to improve working code than start from scratch with a blank piece of paper.
The print syntax described is a perfect example. You don't need any real knowledge of language semantics to do such translations. Do them once, when you adopt a particular source for a Puppy application, and the remaining support can be done in the subset language.
When you get into the business of languages, or libraries, that support everything people might want to do, you are headed for bloat.
I want to put in another vote for Lua. This has so little overhead, and can easily be extended in so many ways, it would make a great basis for scripts. Our problem is that we don't have a lot of Lua scripts for things we want to do. Possible solution: translate scripts in some existing language to Lua. This might not be possible to completely automate, but I'm certain one could do translations which would handle 90+% of the work. Even if the result is far from optimal, 90% of the time this doesn't matter. Besides, there are more programmers who know how to improve working code than start from scratch with a blank piece of paper.