Posts about StupidSheet (old posts, page 1)

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-01-12 19:51

Novell-Ximian-Suse´s future

Lots of people, when they heard of this merger, started thinking like this:

Ok, so Novell bought Ximian. Ximian is a GNOME company. They also bought Suse. Suse is a distro. Ergo, Suse will become a Ximian-oriented distro.

Well, that makes some sense. But they seem to be forgetting of a change that should happen much sooner, because it:

  1. Is easier to do
  2. Makes more sense
  3. Costs less money

What change? Well, the changes that Ximian will have to face for now being part of a company that owns a dsitro!

Let´s look at Ximian´s products:

  • Ximian connector: I don´t see this changing, except for they adding a groupwise connector.
  • Evolution: I can see Novell pushing Evolution as a Groupwise client, for example. So, this has some legs. I don´t see it becoming a major revenue source for Novell, though, so it´s not going to get a large push.
  • Gnumeric: I see an axe in its future. Novell is not in the spreadsheet business. They owned Quattro Pro once, didn´t they?
  • Red Carpet. I have heard Novell really wanted this. They have ZenWorks, I suppose some integration is in order, and this will be productized. However, I don´t think Novell will want to push it as a software distribution mechanism for their competition, at least not while it´s free. If they did, Novell will be giving away what they bought. My guess? It will lose support for Red Hat, and will become more and more proprietary as time passes.
  • Ximian setup tools: I am doubting between the axe and proprietary lockdown. Why would Novell want to support configuration tools for their competition? On the other hand, YaST is better for their own product, so why keep this at all?
  • Mono: I can see they wanting this for their own tool development, and to make a push into the development tool market, but Novell has really no foothold there. So, while they will keep itr and push it, it´s not exactly a guaranteed success (then again, nothing is).
  • Ximian Gnome: I have no idea.

Also, polishing the crystall ball a little, if Novell has some cashflow problems in the next year, they will focus harder in what they really care about.

My guess is setup tools will become SuSE-only or SuSE-first, Red Carpet will be absorbed or rebranded into ZenWorks or something, Mono will be marketed as .NET platfor for Linux as soon as they get Forms working, the rest will be "liberated" fedora-style.

Now, let´s put a reminder to read this again in 2005 ;-)

Contents © 2000-2019 Roberto Alsina