Posts about python (old posts, page 5)

2005-03-15 23:59

Source-based distributions, the good side.

I am no fan of source-based distributions. I think that for most practical purposes, a distribution where installing KDE takes over a day (I own a lowly Duron as my fast computer) is useless.

However, they are good for one particular niche.

Custom distributions. Weird distributions. Personal distributions.

I have several computers. Most of them too slow and small.

As I was considering reinstalling Linux on my Libretto for fun, I looked at what was installed in it, and decided that really, 90% of it was of no use whatsoever.

The problem was, since it had Debian installed, it has a rather wide network of dependencies that simply could not be done without.

On a regular computer, that's not an issue, but in this tiny workhorse, with 16MB of RAM and a 800MB HD, it makes a lot of difference. The smallest I could get Debian to be, and still have network, PCMCIA and X11, was about 250MB.

And the performance was not awesome, either (but not terrible).

So, what would happen if instead of a regular distribution it had something like this:

  • uClibc instead of glibc
  • runit instead of SYSVinit
  • dropbear instead of OpenSSH
  • X built as kdrive (formerly tinyX)
  • python/qt (or maybe python/fltk) for basic admin tools

And so on. Basically rejigger the whole software selection slanting it towards the small side, and dropping a bazillion non-fundamental dependencies along the way.

Well, it can be done. It's just that it's a heck of a lot of work. But here, a source-based distribution gives you a headstart.

For example, I decided to start from ucrux, a uClibc-based port of Crux. Since the native toolchain in ucrux is uClibc, I don't have to worry much about a whole class of mess that happens when you build uClibc-based binaries on a glibc-based system (it's practically cross-compiling).

Qemu lets me install ucrux and work on it somewhat faster than on the target P75 (if I could make KQEmu work I'd be happiest).

Since crux's software packaging mechanism is simplicity itself (a shell script that installs to a fake root), although it's severely underpowered (no dependencies), I can start from ucrux, hack the build of one package at a time, then put everything on a CD very quickly.

So, if you want to hack your own distribution, Crux (or some other similar kit) is quite a nice thing.

For general use... well, my requirements start at apt-get or equivalent ;-)

Now, if only TinyCC worked for more programs, that P75 would be a pocket development powerhouse!

2005-03-09 23:59

Data-aware widgets in PyQt

Here's the challenge: a nicer version of Qt's data-aware widgets, using PyQt.

Did I succeed? Probably not, but it was interesting to do. Maybe it will be interesting to read about ;-)

2005-03-08 23:59

Trac is cool. Cherrypy is cooler.

Trac is cool. Easy to set up, easy to run, low maintenance, and you get:

  • A ticketing system
  • Milestones
  • A webcvs-like thing for subversion
  • A wiki (I mean,. what doesn't provide a wiki nowadays?)
  • Bug reporting tool
  • The bug reporting tool and the subversion changesets can be linked using Wiki markup (now that's cooler than it sounds ;-)
  • You don't need to be root to set it up, and you don't need apache or anything else, really.

Really, really nice stuff.

On the other hand, CherryPy is a tool that lets you "publish your python objects on the web", which doesn't really mean much, but here's what I figured out:

Cherrypy is the first way I have seen to write a useful web-based app in a reasonable amount of time and pain.

Example, I wrote a frontend to clamav (allowing me to remotely trigger scans of individual nodes on a network) using Cherrypy and pyclamav in about 200 lines of code.

It works like a charm, it's robust, it even can be made to look nice using some sort of templating engine (haven't bothered yet).

And of course, I control that baby using a Trac project :-)

2004-12-22 18:58

Games using PyQt

As some may remember, a long time ago I started writing a Bejeweled! lookalike using PyQt.

While that game is actually playable, it mostly showed me I had no idea how to write a decent game ;-)

So, I have been for a couple of weeks trying to create a high level package for creating games, specifically board games (yes, I classify Bejeweled as a board game).

Well, it's working. I am writing a few libraries, and I am writing three games using it.

  • Scroogle: a dumb boggle/scrabble mixture
  • Nameless1: The bejeweled clone
  • Nameless2: A crafty-compatible chessboard

Since I have abstracted stuff like pieces, squares, and such, these games are quite small in size, which means easy to implement!

For example, scroogle can keep score, use a dictionary for word validation, replace used tiles with new ones, so it's basically complete.

It's under 200 lines of code.

The chess game is, again, almost complete, except for stuff like saving games, or board edition, but you can play ( it can't tell if you win or lose and has no timer, though ;-)

It's 210 lines of code (the crafty interface is 70).

Why am I mentioning this? Well, I think that if I ever make this good enough to release it, developing simple games for KDE will become much easier.

And those games will be a 80KB download, including art.

That would be good, wouldn't it? But...

... if you are thinking of writing a game, I need your help. I want you to try using this, so I can figure out if it's good or how it should be changed!

Please contact me if you know a little PyQt and want to write games!

2004-12-14 19:00

This is why dynamic languages are cool

I wrote a little spreadsheet thingie a few days ago. [1]

Of course, it's a toy, not the real thing at all, but it was a nice hack, since it is a real, recalculating, extensible, dependency-checking, loop-avoiding spreadsheet engine in about 50 lines of code.

That's because I was using Python, which is a seriously cool language to write that kind of thing in, since all you have to do to evaluate an expression is call eval() on it.

Sure, that's nice, but the real core of the spreadsheet engine was that you could also create a dictionary-like object that recalculated on-demand its contents.

That way, when you ask for sheet['a1'], custom code goes to see what a1 has in it (a formula), calculates it if needed, and maybe trigger a few extra recalculations if another cell depends on a1. [2]

But as anyone who uses spreadsheets can tell you, weird things exist in ssheet land.

For example, if you copy something, then you paste it, it gets modified in the process.

What other app does that???

Here's an example you can check in any spreadsheet:

  • In A1, type "1".
  • In B1, type "A1+1" (should display 2)
  • In A2, type 2
  • Copy B1 to B2, and it will display 3

Further, if you look at the formula in B2, it says A2+1 now.

That's called relative cellnames (I think).

In order to do that trick, you have to parse the formula in B1, and then, when you paste it into B2, take into account the displacement and modify accordingly. Usually, if you want absolute names, you use $ A1 instead, and that would stay unmodified.

Now, that throws a nice monkeywrench into my neat little spreadsheet [3] because now it suddenly looks not like a spreadsheet at all!

So, I started thinking, how the hell could this be done? The whole advantage of a python sheet is using eval(), so switching to a parser (like if this were a C[++] sheet) would be silly.

I delved into the python standard lib. As every python programmer knows, almost everyhting is there. If you write python, you read the library reference every day, and memorize chunks of it, because it's one of the things that make python cool. It's just chockfull of useful stuff!

And here I was reading about the compiler module, and the parser module, which can be used to do wondrous stuff with python code. But I couldn't understand jackshit about them. I'm a simple coder.

And just as I was going to say, let's write instead about the connection between free software and the sex life of frogs [4] I found tokenize.

Tokenize is a module that parses python and turns it into tokens. Here's how a+2 looks after you tokenize it:

1,0-1,1:        NAME    'a'
1,1-1,2:        OP      '+'
1,2-1,3:        NUMBER  '2'
2,0-2,0:        ENDMARKER       ''

The numbers on the left side are positions in the text stream where the tokens were.

It has just enough information that you can tokenize a piece of code, and then reassemble it. There's code to do just that, it's called regurgitate and it's written by Ka-Ping Yee.

So, the solution is obvious. When copying a formula:

  • Tokenize the formula to be copied
  • Look for tokens of type NAME
  • See if it looks like a cellname, or _cellname
  • If it's _cellname, leave as is. That will be our notation for absolute cells
  • If it's cellname, displace it nicely
  • Regurgitate it

Later, when evaluating a formula, if someone asks for cell _a1 give him cell a1.

And voilà, relative cells.

This works, and it works well (ok, I had to introduce some ugly globals, I need to learn more stuff), and it is guaranteed to tokenize in the same way python does it. It's not even really slow [5]

I touched a bunch of other things, including support for all the functions in python's math module so you can use them in cells. Here's the code to do that:

for name in dir(math):
        if name[0]<>"_":
                self.tools[name]=eval('math.'+name)

Freaky stuff, isn't it?

What's the main issue? Performance. To put it simply, I seriously doubt a sheet written in python can be fast enough for general use. But hey, it's extensible, it's nice, and depending on what you are trying to do, it may be good enough.

And here's today's version of StupidSheet including relative cells. Don't worry, it's a small download ;-)

[1] And almost noone noticed ;-)
[2] That triggering is the only part I wrote myself, the rest is from ASPN's cookbook.
[3] I call it StupidSheet.
[4] I did write that anyway
[5] I don't advice you to copy a formula and paste it into a 10000x200 selection. It will never end. Optimization for this is unexistant. And unlikely.

2004-12-07 19:02

Not a calculator

I have been playing with this code and it's been lots of fun.

I've hacked it into a functional spreadsheet in (according to eric3) 508 lines of non-doc code, of which 244 are generated by pyuic.

Here's my code so far (requires PyQt). Give it a look, I think it's kinda nice.

The only hard part I wrote (at least hard for me) was the cell dependency and recalculation support.

There's a test file you can use, too.

It is trivial to add functions you can use in the cells, just lookup python docs for eval() and check engine.py.

To use it, unpack it, and from the directory it creates run python ssheet.py

I don't plan to make it a real spreadsheet, but it should be fun to hack on :-)

2004-11-15 02:20

On speaking and slides

As I mentioned before, I was at the 3rd CafeLUG event on friday and saturday.

It was a pretty large event, roughly 1300 pople, 63 conferences.

I had two of my own, and here's how they went:

Friday: The PyQt/PyKDE one. Audience: about 50 sitting, 15 standing. I had no time whatsoever to prepare this. But I was luky enough to have someone (thanks Cristian!) lend me a notebook, and so I spent the previous conference (pf/OpenBSD) working on mine :-)

I kept it on a low level, nothing too complicated, since I only had 60 minutes, but the audience seems to have liked it. Or at least they found my attempts at explanation funny.

Anyway, noone was disgusted enough to tell me to my face, and I had a general feeling of it having been good.

I was able to show a quick do-nothing app in 20 lines of code, and show signals and slots, and really really push the idea of interpreted languages as better for hobby programming (which I think is the right path). Not too many questions right then, but about a dozen kids attacked me with questions on the hall after leaving.

Saturday: My generic KDE-for-beginners speech. Audience: 100 sitting, 10 standing. I was a bit too heavy on the philosophical, but it went down nicely. Several of the guys from friday's PyQt session were there, so more evidence it didn't suck too badly.

It was fun, people were surprised by Ogg-ripping from Konqueror as usual, some fun, several questions.

All in all, a nice couple of sessions, and I think I did well, which encourages me to do it more often. Who knows :-)

2004-10-22 14:31

Some KDE-related hacking

Since porting HTML display engines from one place to another is all the rage these days, I did a little hacking on one of the oldest forms of the art:

KDE's kdenox module contains konq-embed, which is, among other things, a port of KHTML to almost-pure-Qt (I think).

So, I am hacking to make that really-pure-Qt.

So, it's basically porting KHTML from KDE to Qt.

Why? Because I want a decent HTML widget for PyQt that doesn't require kdelibs. So people using PyQt/Win32 can use it, for instance.

I don't know if it will work (hacking C++ code is almost painful to me nowadays).

2004-10-15 11:11

Now, this is news to me.

Tavia seems to be another KDE web browser.

I say nice.

Semi-related:

Because of a question on the PyKDE list, asking for a more complete HTML widget using Qt (not kdelibs) I am looking at kdenox, which is supposed to be a Qt-only (QT/E) konqy. Perhaps ripping off the khtml piece of it won't be too hard, and then it can be sip-wrapped.

Probably nothing will happen with it, but I am looking ;-)

2004-10-13 16:24

On other news today...

Python code really doesn't look good on planetkde, so follow the link to my page to see it right if you are there ;-)

Contents © 2000-2019 Roberto Alsina