Older blog entries for uzi (starting at number 4)

Well, I'm suprised, but it took me pretty much a day (knowing next to nothing about gtk+ to begin with) to write a usable gtk+ interface for cscope. It's simple and straightforward... and the help of the great tutorial and my buddy yosh (who nontheless made sure I did all the code) were invaluable. I'll probably be doing more gtk+ coding down the line... and it's a nice change from the system-level stuff I'm used to poking at anyways.

The results? See for yourself... screenshots of the curses and gtk+ interfaces in their current state. Lots of work still needs to be done, yeah... but they're at least usable once I hack up the backend to work with 'em. Once that's done, I hope the real fun begins. :)

Note to self... make sure phil gets my ricochet modem from dria so he can return it to me when he comes here next week. :)

Well, cscope's interfaces are coming along fine so far. The initial interfaces will be working but bare bones with much room for improvement, just like the backend. Fair enough... hopefully there will be much, fun and most importantly valuable hacking to be done.

The curses interface is working... just need to clean it a bit and such, but it's at a usable point. Stuff like color, handling SIGWINCH, exactly how and what I want displayed, and general bugfixing (including portability) is what's left here.

The gtk interface is starting to come together. Again, some beautification, features like coloring, etc. will all be doable.

I should hopefully have both in place for that initial release. I also intend for the two to use the same code right up to the interface code with two separate binaries. Just having something working is my initial goal, and meeting that is not too far out of reach...

Well, just because it'll make seklos's day, I'm doing another diary entry. Who knows why it matters so much to him... he's a weirdo. ;)

Actually, all I really have to say is that my cscope's curses interface is now pretty much done... I just need to fix up a fewminor bugs, but it's at the point of working. Now I need to work on the backend stuff. It hopefully won't take too long... I'm making decent progress. Stay tuned. :)

Oh man this sucks. I have a machine here that I use as my file server, and the 9GB 7200RPM Quantum SCSI disk I have for /home just died... which basically means I've lost a lot of data. Fortunately I still have a lot of my other data on other disks... so all is not lost... just inconvenienced.

Also, I've started hacking up an open sourced cscope. I'm working on the (n)curses interface for it right now... much more work to be done, but I should have *something* available in the not-too-distant future. The initial version will be functional but limited in power. I'll try to do a gtk interface for it before I release as well. All in good time, though.

Heck, email me if you have questions or are interested in joining me in this effort when I'm a bit further along.

Man, it would be nice to have a decent open source cscope implementation... I have my cgvg scripts... there's LXR... and even id-utils. Oh yes, can't forget cs, which is a poor cscope clone (but have you seen the license?)

So, cgvg is somewhat adequate. It was written to be a quick hack and I just added stuff here and there and got it into it's present state. It's written in 100% Perl... and does a decent find/grep-like job... but if you have a large tree (like the Linux kernel), it takes a while.

Then there's LXR, which is good for reading the code... but not for being interactive with it. I've been hacking up it's code (also in Perl) a bit... and I *could* use it to do an addition to cgvg that understands C/C++ to some degree (it'll tell you where things like functions are declared, where they're prototyped, where they're referenced, etc... but not much more). Generating the database also isn't the speediest of things.

id-utils is much faster at that, but also more limited. It only really does lexical analysis... no real parsing... so it's good for identifiers, but not for what the identifiers really are. I could easily use it to make a faster version of cgvg, though... though it would be a bit limited in comparison.

Finally, we have cs, which is an attempt at doing a cscope clone. The code is kinda ugly, and it's limited to C (while I really only code in C, I'd want C++ support). It's also limited to small projects. Also, look at the packaged manpage near the end to see its license. Not a pretty thing... I certainly wouldn't work on it.

Yes, I use and love ctags, but it only takes you to where things are defined... not other way around, along with other functionality.

The best course of action would be to do a real cscope clone. The problem is it's a _huge_ undertaking. I can write it, yeah... but it would take a long time. I'm wondering if I did it, would anyone really use it? It's also kinda hard to tell people you want "cscope", since most people aren't familiar with it. I'll just have to sit and ponder it a bit. And heck... if anyone else is interested in working on such a beast, feel free to email me. Just, with such a project, I'd want to sit and be sure it's what I really want to spend countless hours of my life working on... or would the time be better spent on other things.

On that note, I bought a pretty bare SparcStation 20 today that I'm going to build up with parts I have lying around here... that brings the total to 6 SPARCs. :)

BTW, hi phil... sorry for the mess. (It wasn't *that* messy, was it?) I guess I paid for the mess with garlic bread. ;)

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!