tinypy, a really tiny Python

Stuff that has yet to be sorted into a category.
Post Reply
Message
Author
User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

tinypy, a really tiny Python

#1 Post by BarryK »

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.
Attachments
tinypy-1.1-static.pet
(56.2 KiB) Downloaded 1405 times
[url]https://bkhome.org/news/[/url]

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#2 Post by amigo »

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

User avatar
rarsa
Posts: 3053
Joined: Sun 29 May 2005, 20:30
Location: Kitchener, Ontario, Canada
Contact:

#3 Post by rarsa »

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.
according to the web page wrote:a fairly decent subset of python
As you pointed out "print" is a good example.

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

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#4 Post by BarryK »

If anyone is interested, I got the latest tinypy out of SVN and compiled it with Dietlibc. This is how:

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 "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:
Attachments
tinypy.gz
(47.85 KiB) Downloaded 971 times
[url]https://bkhome.org/news/[/url]

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#5 Post by disciple »

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?
Do you know a good gtkdialog program? Please post a link here

Classic Puppy quotes

ROOT FOREVER
GTK2 FOREVER

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#6 Post by BarryK »

tinypy and gtkdialog would be a good match for GTK GUIs.
[url]https://bkhome.org/news/[/url]

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#7 Post by disciple »

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.
Do you know a good gtkdialog program? Please post a link here

Classic Puppy quotes

ROOT FOREVER
GTK2 FOREVER

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#8 Post by BarryK »

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.
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.

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]

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#9 Post by BarryK »

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.
[url]https://bkhome.org/news/[/url]

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

Python and/or Lua

#10 Post by mcewanw »

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).

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#11 Post by technosaurus »

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].

DMcCunney
Posts: 889
Joined: Tue 03 Feb 2009, 00:45

Re: Python and/or Lua

#12 Post by DMcCunney »

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...
I have it running on a Palm OS 5 device. There's a Plau 2 rev for Palm OS as well.
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.
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.
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.
As I recall, Damn Small Linux makes extensive use of Lua.

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.
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 mentioned, getting embedded like that is a design goal for the language.
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).
As long as no one suggests replacing existing Bash scripting with Lua.
______
Dennis

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

why not a translator?

#13 Post by prehistoric »

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.

Post Reply