Slashdot Mirror
Gnumeric Turns 5
Jody Goldberg writes "Five years ago, Miguel committed the first code for Gnumeric to CVS. In a testament to the quality of the code several lines are still in use. Since that time the project has grown to more than 300,000 lines and now supports all 325 worksheet functions in MS Excel, plus almost 100 more. This seemed like a good time to thank all the people who have contributed to Gnumeric over the years. We're about to start the run up to the the next stable release which will be out in a few
weeks and we look forward to continuing work with GNOME, and the community at large to produce the most powerful spreadsheet in the world."
I use gnumeric all the time, I read MS xls files without any problems. Its also faster to start, and looks better, than OO (which I also like). Its my favorite of all of the Linux office apps.
I use MS Excel almost everyday for data analysis, and the most annoying part is that number of records cannot exceed 65536 in Excel. Anyting larger than that, we need to get the data into Access and work in it, and that's not very fast and easy. What's the limit in Gnumeric?
New year Resolution: Don't change sig this year
Our goal is to produce a great spreadsheet.
Compatibility with existing products is required for people to be able to transition. We already have significantly better analytics than MS Excel. Over time we hope to become a superset of it in other areas too.
Five years ago, Miguel committed the first code for Gnumeric to CVS. In a testament to the quality of the code several lines are still in use
It's nothing. As a testament to the quality of the Windows sourcecode they keep seleral lines of code back from the early eighties in active use.
I'm serious. People in the Windows world use Excel not only to calculate stuff, but as some kind of application platform. Personally I think that's stupid in most cases, but not offering it is even worse.
Maybe I just couldn't find it anywhere, but: Is Gnumeric easily scriptable? It doesn't have to be Excel or VBA compatible (in fact, about every other language would be better, IMHO), it doesn't need an integrated IDE with debugger etc. like Excel has, but the only thing I could find so far is a "plugins" directory containing .so files - that can't be it. Is there something better, and if so, why the f**k isn't it documented prominently?
Programming can be fun again. Film at 11.
There are two somewhat related issues to contend with.
1) The file formats are semi documented. We have rough ideas of what OLE2, BIFF[5-8], and escher look like. There are however, lots of abiguities and question marks. As a result we have lots and lots of validation on what get imported. OOo does the same, which is why we can frequently crash MS excel when adding something new to the xls exporter, but still be able to read each others output.
2) The format for VBA is undocumented a far as I know. OOo has a few guesses in place and I've started doing some research on it, but neither of us can even read the vba enough to worry about running macro viri.
3) what scripting capabilities we do have (eg in python, perl, or guile) are strictly sandboxed. We are definitely tending to err on the side of caution rather than functionality.
Please don't judge all of gnumeric based on the text import in 1.0.x. There have been lots of performance improvements and enhancements there in the development series. The core of gnumeric is easily capable of handling that magnitude of data. Try 1.2.x when it comes out next month (or even 1.1.x if you want to help beta things).
MS Excel is still somewhat faster mainly due to its memory foot print. It was written back in the day and bit bashes things all over the place. Gnumeric pays a penalty for using 32bit addresses rather than bit bashing 18.
If you have something that performs badly please _tell_ us. Our goal is to produce the best damn spreadsheet around. This is still version 1.1, 2.0 (extend) and 3.0 (extinguish) aren't due for a while yet.
We tend to split extension into 2 areas
1) writing functions. Which is supported and documented in python, perl, and guile (and of course compiled languages)
2) scripting. Which is currently unfinished and intentionally mostly undocumented. There are some experimental bindings for python, but we have not had the time to select a solid enough api that we could commit to it. Gnumeric tries to under promise features, and I don't want to whip out some half baked api. The 1.3 development cycle will target scripting and we'll likely wrap the selected api in python, perl and corba initially.
We could use some help on this.
How well does Gnumeric handle xls files from non-English versions of Excel?
In particular, the formulae in non-English versions of Excel are saved into the xls files using their non-English names - can Gnumeric cope with that? (This is totally brain dead behaviour, IMHO, - not only does it mean that an English Excel can't understand non-English files, but if the function name has a non-Latin 1 character in it and you don't have that font, then even if you have the right language version of Excel you still can't edit the formula, only run it! This kills sharing Excel spreadsheets internationally. Why, oh why didn't they use numeric codes in the file and translate?). [Disclaimer: I've seen this for Excel = v.97, haven't looked at newer versions.]
As a side question, how does Gnumeric save formulae in its own-format files?
I originally tried Gnumeric a long time ago, in v. 0.something, at the time it didn't have the functionality I needed. I shall certainly try it again. Thanks for all the hard work!