In tinypyC++ every variable is a certain type.  In some cases I may have an int x = None;  But I’m not sure what that should mean?

What’s the most pythonic? Here’s some anecdotal evidence:

>>> None,None==None,None==-1,None==0,None==1,None==False,None==True,bool(None)
(None, True, False, False, False, False, False, False)
>>> -1,-1==None,-1==-1,-1==0,-1==1,-1==False,-1==True,bool(-1)
(-1, False, True, False, False, False, False, True)
>>> 0,0==None,0==-1,0==0,0==1,0==False,0==True,bool(0)
(0, False, False, True, False, True, False, False)
>>> 1,1==None,1==-1,1==0,1==1,1==False,1==True,bool(1)
(1, False, False, False, True, False, True, True)

So .. you can see -1 gets 4/7.  0 also gets 4/7.  (1 gets a mere 3/7, so it’s out.)

Anyone care to tilt the scales to -1 or 0?

So after some discussion yesterday with a few folks about Exceptions in C++, I decided to add a compilation flag to disable the use of exceptions in tinypyC++.  The claim given to me was around these few items: 1. Exceptions slow your code down.  2. Exceptions aren’t cross-platform (in some cases).  3. Exceptions can easily add in memory-leaks.

I can’t argue with #2, although it’s not completely relevant for the platforms I’m targeting right now.  #3, with the way tinypyC++ does reference counting, I wouldn’t be surprised if this could happen.  #1, I figured might be true, but I wanted to know how real #1 actually was.  So here are my results:

In the first test I’m rendering a Julia fractal for 20 frames and averaging the time it takes to render. In the second test (below) I’m doing the same test, but I did one code optimization to remove a new/delete that was happening for each pixel – by reusing the coordinates object.

I found it interesting that in the 2nd test case I did, removing exceptions actually increased the time it took to render the fractal!  Not quite sure why .. hmmm.  (I tried it a few times and kept getting similar results too.)

What is clear in the second test is that the compiler is able to optimize the code much more aggressively.  I guess Exceptions choke up the optimizer.  In all cases it seems that adding on the -g flag seems to make the code run slightly faster, surprisingly enough!  (-g adds in debugger info.)  In all cases, the optimizer was able to roughly double the speed of the program, and when I disable exceptions it is able to throw in even more speed.

-Phil

Here’s a screenshot.  This is my Ubuntu desktop of my work on a new iPhone game.  Take a look at it nice and big.  Below I’ll explain all of what is going on …

In short, I’m working on porting my pyweek#3 team entry to the iPhone.  Here’s the details:

• Top left, you see Kate, my text editor.  You’ll notice I’ve got -what appears- to be python.  But that’s actually tinypyC++ code!  My converter still has some rough edges, but it’s starting to get pretty good.  If you weren’t looking to closely you might mistake that for ordinary python code!  (In fact, it should be 100% python parser friendly.)  You can see how I have to use a touch of annotation to make it all go.  But for the most part, the types get inferred.  (The C++ outputted is about 2x as long, so I’m saving a ton of keystrokes!)
• Top right, you see the level being painted.  It isn’t all working yet, but those are the basic tiles.  Interesting bit about loading the level, when I created this game I used my own level editor and library I made with pygame.  To save on disk and time I save all the levels to .tga files.  Since I’m targeting the iPhone I need an easy way to read the data from .tga files.  I don’t have SDL_image available, so a friend pointed me towards this great site.  It appears to have some awesome bits of code, including very simple and easy to use image loader that can load tga/png/jpg/etc.  I think it has the most painless interface I’ve ever seen for a C-based image-loader.
• Bottom right you can see me working on tinypyC++.  As I’m working on BSA, I’m always finding new bugs in it.  Lately most of the bugs have been of the “add more graceful error handling” nature.  tinypy will point out what line (and character) an error happened on, but with a bit of extra work I’m able to add in some coherent error messages to tell the user what is going on.  In this case it was to inform the user of an undefined module name.
• Bottom left you can see the startup of the game.  I’m using irrKlang for all my  game audio now.  It is not open source, but it’s “free” to use for free games, and the price is quite reasonable for commercial projects.  irrKlang is not portable to the iPhone yet, so I have to have a separate driver for my iPhone audio.

And that’s it for today’s report!

-Phil

I’ve spent the last week working on a tinypy to C++ converter.  It works!  See the screenshot to the right – I’ve managed to port a pygame game over to C++.

Here’s how (and some of the catches):

• I require type annotation of all the functions and methods.  “def test(x:str)->str: return x”
• I do two passes on each file, the first pass to catch all the function types and class members, and the second pass to generate the code.
• I generate C++ code that has automagic reference counting.  So you have to code your script so it won’t have any cyclic references if you want garbage collected for you.

How is this different from shedskin (really cool project!)?

• Built-in reference counting, instead of using libgc.
• I require the user to type annotate everything.
• It only supports a subset of the tinypy subset of python.  Shedskin supports a much larger subset of python.

So what’s the point?

• Well, I learned a lot about STL and C++.
• I know it will produce iPhone friendly code, I’m pretty sure libgc isn’t iPhone friendly?  (At least, I haven’t found anything via a few searches…)
• Way less magic.  Since everything is annotated, there are no surprises.
• Implementing C++ modules is pretty easy – the code can be inlined within the python code and it just works.
• This will make it easier for me to develop C++ games.

Anyway, if you’re super brave, you can check out svn://www.imitationpickles.org/tinypy/branches/tinypy2 .. I don’t have the elephants example in there, but the pygame.py that I include gives you a pretty good example of a complex module.

I’m going to chat with the tinypy folks to see if we’ll merge this into the tinypy trunk or have it as a separate project.  I’m not quite sure what makes sense to everyone else 🙂  The nice bit about merging this in is that I could unify the test suites nicely.  And tinypy would still function as normal, just better tested, and with function annotation parsing supported.  All that said, I should make a tinypy module for tinypyC++ so that I can do some code evals!

So .. who thinks flash + Galcon = win?  I don’t know yet, but I’m giving it a try.  I’m not actually developing the flash version.  An awesome friend of mine has been doing the time on this one.  Though I’ll probably be doing the LAMP end of the deal.  At present the game is non-networked, but we’re been considering the possibilities.  A TCP/IP edition of the game could be made, but I wonder if that would end in tears.  TCP/IP isn’t ideal for gamedev IMO.  Flash doesn’t support UDP as-of-yet.

This isn’t the first time Galcon has reared it’s head from within the browser window.  (See my earlier blog posts …)

I haven’t decided exactly what I’m going to do with this once it’s completed.  Probably a few things.  Throwing it on facebook is an obvious one.  Throwing it on galcon.com is another one.  Maybe mixing it with something like The Maze of Madness is another one.  Or maybe something else!

One idea that I have that would be really cool would be if the tinypy vm were ported to ActionScript using Alchemy* .. and then somehow people would be able to script Galcon on the web and share it with their friends..

*I don’t know if you caught that .. but I think my weekend just got booked 🙂

Alas, I’m not going to be able to make PyCon this year .. Because I’m a finalist in the IGF Mobile competition 🙂  And the GDC is happening the same week as PyCon.  Oh well, can’t do everything.  I wish I could go to both, PyCon was a blast last year!

That said, some of us tinypy folks might do a tinypy sprint at the same time as the PyCon sprints.  So if there are any people at PyCon who want to sprint on tinypy, get in touch and we can all work together in #tinypy somewhere.  Further news about this sprint will be available in the tinypy mailing list.

tinypy has progressed a bit since I last posted about it.  It’s probably sandboxed and it now has meta methods.  If there are some serious smart VM coders who are interested, we could use a hand.  tinypy is as fast as python for some tasks, but for other things it is around 1/2 the speed of python.  It also uses more memory than python.

Hey,

So .. I’m thinking about proposing a talk about tinypy at pycon.  Not quite sure what I’d want to say about it.  So, here’s my “ask the web” question:

What do you want to hear me talk about tinypy?

I could talk about anything from how I made it, why I made it, what good it is, how to use it, to .. err .. I dunno.  Whatever 🙂

If no good talk ideas come together, I’ll probably do a lightning about it again, and maybe an open session.

I also want to do a Galcon tournament of sorts again at some point 🙂  That was great fun last year!

-Phil

I’ve learned a lot about python by implementing tinypy. Today I was thinking over my re-work of classes, objects, and inheritance in tinypy (not in trunk yet). I noted how in tinypy, I will be able to change the class of an object via a function call (a-la lua):

class A: pass
class B: pass
x = A() # x is an instance of A
setmeta(x,B) # x is now an instance of B !!!

So I thought to myself, I wonder if python can do that. Well, it can, and as per usual, its solution is quite elegant:

class A: pass
class B: pass
x = A() # x is an instance of A
x.__class__ = B # x is now an instance of B !!!

So, lesson of the day — you can dynamically change the class of an object in bigpy. Which, actually, I’ve sometimes wanted to do, I just didn’t realize I *could* do it.

Man, could I have even thought of a title that sounds dustier? It just screams “Get ready for the boring lecture of the year folks.” I should totally re-name this post to something like “putting your brain through a blender .. FOR FUN!” Or maybe I should have gone the pretentious route and named it something like “Analysis of modern programming meta-method paradigms.” Actually, that sounds even dustier than my original title. At least my original one falsely implies that there is some competition going on in this post by my use of the “vs”.

Here’s how python does it:

class X:
    def __get__(self,k): return “OK”

Here’s how tinypy does it:

class MetaX:
    def __get__(self,k): return “OK”
class X:
    def __init__(self): setmeta(self,MetaX)

Okay .. so .. the python way is WAY more readable. Nice 🙂 So let me remember if there was a good reason for doing it a different way in tinypy … I think the answer is “maybe” ? Here’s what I can come up with:

• In tinypy dict == object, which means a.x == a[‘x’]. (I’m not sure how that’s relevant, but it does mean that I have no need for a __getattr__.)
• lua does it that way! (I have copied many other lua design decisions, so why not copy another!)
• It’s faster? (In a sort of, if only tinypy were as fast as python is to begin with kind of way.)
• It was easier to hack together in an afternoon! (Well, actually .. looking at the python code, I think the python way might have been easier.)
  

So what did I gain by going the lua route instead of the python route? I’m not entirely sure .. but it sure seemed like a good idea at the time.

A few days later …

With a bit of effort, I’ve come up with a few more reasons why I did this in tinypy:

• Not only are dicts objects but they can also be classes. This is done by having a __call__ meta, so if you have class X: .. X() calls getmeta(X).__call__. This is relevant because if the class itself had a __call__ method, how would you define your class so that it knows to create your object with a __call__ method? (Probably by having a __new__ method that isn’t copied to the object.)
• The one way the previous point is relevant, is that the object __new__ would probably have to be smarter than how I create objects currently. It would have to realize that __new__ methods don’t get copied into objects.
• Also, I would probably have to internally track what is a class vs what is an object. So I know when I do something like X.test(self) .. and my class X has the unbound method of __get__, it knows not to try any meta magic.

Okay .. those aren’t great reasons. The nice thing about tinypy being .. tinypy .. is that if this continues to bother me for the rest of the day, I can probably try out the implementation in a couple hours. If you want to see the current meta implementation, it’s in subversion.

Anyone care to comment on the whole lua vs python style meta-methods stuff? I’m pretty sure I’m not sure at all what I think about them!

Here it is: http://tinypy.googlecode.com/files/tinypy-1.1.tar.gz

tinypy is a minimalist implementation of python in 64k of code.  If you want to get involved, be sure to join the mailing list!

Thanks loads to everyone (allefant, Seth, Krzy, Rockins, Dean) who helped get this release together 🙂

The highlights are:

– works in VS now
– math module
– better setup.py
– a million bug fixes

Enjoy!
-Phil